GitLab

(now that allgo supports multiple e-mail addresses per user, they
 can resolve the problem without the admins)

- remove the HasSignedTosMixin and to the verifications in
  AllgoAccessMixin instead (along with email verification)
- add Tos.get_latest() and User.has_agreed_tos
- ignore ToS agreement if the db has no ToS entries

BERJON Matthieu authored Nov 07, 2018 and BAIRE Anthony committed Dec 06, 2018

I added a mixin that checks if the user has accepted the latest ToS
version. If not the user is redirected to the ToS validation view. Once
accepted the user is redirected to the page he asked first.

I updated all the `login required` views by adding this new mixin.
One major issue of this code that the redirection argument passed to the
ToS validation view is the url name which is not a good practice I
think. A better case would to use the path but I wasn't able to write
the right regex in the url dispatcher.

Another issue is that the user won't be redirected at login or sign up
to the ToS validation view. This should be handled in the `adapter.py`
file.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

BERJON Matthieu authored Nov 07, 2018 and BAIRE Anthony committed Dec 06, 2018

I added a view to display the latest version of the ToS. This include a
specific url, its related view and template. I edited the footer as well
to add a link to the ToS.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

There are multiple reasons:
- we can use the same page for validating the 'Terms of Use'
- the user may already have received the message
- we should do the same validation on the API too (but API should not
  send any email but just display the error message)

email.addresses lists all email addresses belonging to the user
thus we can make more generic queries

also adds EmailAddress.is_provider

remove the IsProviderMixin and introduce 3 new mixins:
- UserAccessMixin     -> must be a registered user
- ProviderAccessMixin -> user must be a provider
- AllAccessMixin      -> may or may not be a registered user

All these 3 mixins will also ensure that the user email is validated.

The purpose of the AllAccessMixin is to force the validation of the
email when the user is registered, thus the validation will be
requested when landing on the webapp_detail page rather than when
submitting the first job (which would be discarded)

webapp lists should never display apps not visible by the request.user
(obviously!)

TagWebappList did not implement such a filter. I added the
query_webapps_for_user() helper and use it for TagWebappList, TagList
and WebappList (the list returned by this function is the superset of
webapps that these views are allowed to display).

(for convenience)

Checking user.email is not ok because allauth allows multiple
addresses per user but grants access if any of them is verified.

-> we need to ensure that the matched address is verified


Thus a (non-admin) user can import a webapp only if the two
conditions are met:
- the user is allowed to create webapps (verified by IsProviderMixin)
- the user has a verified email address that matches the owner
  address of the imported webapp

The redirection in case of success was wrong. I changed it to redirect
to the webapp update page.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I merged the `UserWebappForm` into the `WebappForm`. I updated the views
accordingly.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

- use the same mixin for the api and the UI (so that the authorization
  code is not duplicated)
- renamed JobAuthorizationMixin as JobAuthMixin (because it is easier
  to type ;-)
- LoginRequiredMixin is no longer required because authentication
  (and redirection to the login page) is handled by UserPassesTestMixin

- supports authentication by cookie and by token
- checks the syntax of the Authorization error and handle errors
- returns a User object (instead of AllgoUser, because it is more
  useful)

Note: /auth was broken because it misused a AllgoUser as a User

This adds two views:

- WebappImport for importing the webapp (but without the versions).
  The import is allowed if the requesting user has the same email
  as the owner of the imported app. The webapp is created with
  imported=True, which enables the WebappVersionImport view

- WebappVersionImport for requisting the import of webapp version.
  This only creates the WebappVersion entry with state=IMPORT
  (the actual import is performed by the controller)

A version may be imported multiple times. In that case, the newly
imported version overwrite the local version with the same number.

This features requires:
- that the rails server implements !138
- that the docker daemon hosting the sandboxes is configured with
  credentials for pulling from the legacy registry

When 'versions' is empty, the « From an existing version » option in
the template is hidden. However reversed() returns an iterator, which
is never False -> need to coerce versions into a list.

close #249

- add config key ALLGO_WEBAPP_DEFAULT_MEMORY_LIMIT_MB to set the
  default memory limit for newly created webapps

- add memory limit field in WebappUpdate

- display memory_limit in megabytes in the UI (through the
  memory_limit_mb form field)

- disable the memory_limit_mb widget and ignored the posted value
  when user is not superuser

- forbid negative value in the model

- make the memory limit field required in the forms

I exchanged the `GroupRequiredMixin` by `IsProviderMixin` in every
relevant views.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

close #272

close #269, #270

Note: checking os.path.exists(job.data_dir) is no longer required
      since the data dir is always created (even if the job has
      no input files)

- fix url conflict for .zip archive download
- fix empty zip file

close #268

(was not used at all)

because django sets a foreign key constraint on sandbox_version_id
we may have issues if it refers to a version we want to delete

With this change docker images are no longer
named as: <Webapp.docker_name>:<WebappVersion.number>
but       <Webapp.docker_name>:id</WebappVersion.id>

This is only for storage, for the user we still present the image as
<Webapp.docker_name>:<WebappVersion.number>

There are multiple reasons to do that:
- this simplifies the controller design, because docker images are no
  longer replaced (once an image is committed with tag, 'id<SOMETHING>'
  it won't be modified anymore) -> thus it is no longer necessary to
  track the image state carefully (when pushing/pulling from/to the
  registry)
- this prevent reusing dangling images from a removed webapp (because we
  now have a strong guarantee that the image tags are unique)
- this will avoid nasty race conditions when we implement direct 'push'
  to the registry (because we then assign the new image id before the
  manifest is actually pushed, if a push and commit are done in the same
  time we will keep the latest one, i.e. with the highest id)
- this will make easy to implement image recovery: we can keep removed
  images in the registry for some time (eg: 1 month) before they are
  really deleted

Note: the REPLACED state is no longer transient (since we now keep the
replaced images in the db and since we may still have remaining
job/sandboxes using them). Maybe we can rename it as DELETED when we
implement #265.

I created a `JobAuthorizationMixin` that overrides the `dispatch` method
to check of a user can access a given job. It sends a 403 error if he
can't.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the `dispatch` method in order to give to a superuser the
right to see any given jobs. I added as well a small docstring.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>