djaodjin / djaodjin-signup Goto Github PK

Named /api/auth/pubkey/<user>/ to follow current convention (aka /api/auth/keys/<user>/).

We will count as a daily active user one where start_of_day(yesterday) < User.last_login < end_of_day(yesterday). This will be used in dashboard widget:

• This API endpoint could also be used to show a graph of daily active users through time. So it could/should be modeled on the model of saas.api.metrics.RevenueMetricAPIView for both request parameters and result JSON schema.

• The definition of start_of_day/end_of_day should take into account timezones to make sure metrics do not change based on where the browser making a request is located.

This issue was originally opened here in djaodjin-saas.

@marmida said:

Validation rules fire that prevent the entry of non-ASCII content into the registration form. See the attached image.

This may be specific to the wrapping site, or may be part of the djaodjin-signup core. I'm not certain. It should be the case that the registration form instead allows non-ASCII input.

A POST to /api/auth/recover/ with an email address should trigger a notification to the user so she can recover the account. Currently this functionality is only available through the /recover/ page URL.

The request.user password should be passed along on POST /api/users/<user>/password/, POST /api/auth/keys/{user}/, POST /users/<user>/password/, and POST /users/<user>/pubkey/.

upload them to a S3 bucket.
Find out if there is a JS widget that will resize picture before upload

• Add a second login form in the testsite such that login, instead of returning a session cookie, uses the JWT login API to return a JSON Web Token.
• Add a second register form in the testsite for doing the same for register.
• Upgrade the vuejs component to generate requests with the CSRF/Cookie or JWT authorization header.

Create a model for Notification, API end-point and HTML views such that a User can pick and choose which notifications she wants to receive.

When trying to signup I get this ValueError: The given username must be set. The problem is that username field is always empty in the file signup/views/users.py on the line 266. And apparently the NameEmailForm is not expecting a username parameter, while the call on line 266 is trying to fetch the field from the form data.

In signup/settings.py, DISABLED_AUTHENTICATION, DISABLED_REGISTRATION are used to enable/disable authentication and registration globally. This needs to be changed to use the output of a function instead. The function will look like the following in saas/models.py:

def get_broker():
    """
    Returns the site-wide provider from a request.
    """
    from saas.compat import import_string
    LOGGER.debug("get_broker('%s')", settings.BROKER_CALLABLE)
    try:
        return import_string(settings.BROKER_CALLABLE)()
    except ImportError:
        pass
    return Organization.objects.get(slug=settings.BROKER_CALLABLE)

Rework the workflow after login to support double factor authentication.

1. Introduce Contact.verification_token and Contact.verification_token_expires_at fields to hold the second (generated) factor.
2. Based on the design for get_broker, retrieve a settings to enable double-factor authentication.
3. Emit a signal that will implement sending the verification_token to the user (defaults to e-mail in testsuite).

We cannot import extra mixins otherwise.

1/ Calling uploadImage in djaodjin-signup-vue.js results in a permission denied. This is due to an $.ajax call without authorization / csrf headers.

2/ uploadImage should use a dedicated API end-point name even if in some cases it will default to djaodjinSettings.urls.user.api_contact (Ex: djaodjinSettings.urls.api.upload_profile_picture).

3/ Reviewing the #user-profile-container widget, updateProfile is also not working in the presence of a profile picture because saveProfileWithPicture and saveProfile do not exist. In all cases, There should only be one PATCH request in updateProfile.

4/ Rename uploadImage to uploadProfilePicture to be more accurate.

waiting for django-recaptcha, social-auth-app-django and social-auth-core to support Django 4.0.