ninjablocks / douitsu Goto Github PK

Seems the current douitsu doesn't require the confirmation email to be clicked before letting users on.

Is there an option to make this a required step in the signup process?

When editing an Application or Account Profile put an asterix (*) next to the title to signify that the record is dirty and needs saving.

eg:

Clean: "Y O U R A C C O U N T"
Dirty: "Y O U R A C C O U N T * "

(We may change the visual indicator/style for this as long as the flag to turn it on and off is there)

When I register the user is created by displays the rather unhelpful.

That email address is not recognized.

Down the bottom in red.

After clicking on Allow on https://staging-id.ninja.is/dialog/authorize?response_type=code&redirect_uri=http://localhost:3001/auth/example-oauth2orize/callback&scope=email&client_id=123 the redirect goes to https://localhost:3001/auth/example-oauth2orize/callback?code=rfe3441zwwo2h4ir (i.e. https instead of http as defined in the redirect_uri param).

I'm not sure but as far as I can tell this is because nginx is configured to always redirect to https because /etc/nginx/conf.d/douitsu.con has the following:
proxy_redirect http:// https://;

Need to provide a method to enable signup via a mobile application.

When I launch this service with a DB_URL set the system seems to create all the seed data EVERY time.

Need to move all this Spec logic out of the main app otherwise it is going to be hard to deploy.

This needs to be moved out.

https://github.com/ninjablocks/douitsu/blob/master/lib/douitsu.js#L219-L260

Would be nice to be able to run a script to seed the system if required, for either PROD or DEV.

No activation email is received from system when registering a new user.

User cannot resume application authorisation if they choose to sign up and create an account half way through the process.

App auth process should remember which app the user is wanting to auth and continue the auth proces once they are signed up.

To alleviate the dependence on the email address, which can change we need an identifier an OAuth2 client can key on for a given profile.

At the moment the best candidate for this is the users UID.

Need to look into making this change here and then updating the cloud web application.

To reproduce this issue run:
$ mocha test/issue_8_update_user.test.js

To reproduce this issue in the browser:

• Open http://localhost:3333/signup
• Signup with test and [email protected]
• Open http://localhost:3333/account/#/Account
• Change name to test1
• Click on Update
• Error 'Unable to perform your request at this time - please try again later.' is returned

This error also occurs if no fields are changed.

The logic in cmd_update_user in seneca-auth/lib/auth.js checks the uniqueness of user.nick before updating the user and this is where the error originates from.

Side effect: This error message also occurs if the email is changed to another existing user's email but that's because there's no validation check to see if that email exists already.

This bug can also be reproduced in https://github.com/rjrodger/seneca-mvp.

I followed the instructions in the README.md and got stuck in a couple of places.

Firstly the gulp script runs through normally then just blocks without reporting why. I am guessing this is because it is in dev/watch mode. Either the default target should be changed or a new target added for build and the readme updated.

Either way it would be nice to know what it is doing..

Also need to add some notes on what ENV vars/config modes there are for dev or prod.

Just a list of what is expected would be nice.

Some of the configuration seems to be related to customisation, and some to env related configuration.

First I would stop using LDAP_ENABLED as a var all over the place, people may want to disable signup if they are using MySQL login.

Second need provide an authoritative reference configuration with all the options along with comments on whether or not these can be over ruled by ENV vars or not.

Thirdly I would prefer if MySQL/LDAP/REDIS could be configured via env vars, then use configuration as a fallback.

How can custom themes (Frontend HTML/CSS/JS) be loaded per app.
ie: presenting different login/auth screens for each app. We can have a default theme but will need to customise certain apps for overall UX approach.

Updating a User Profile photo or Application photo doesn't appear to work.
May need an uploading progress animation for user feedback.

Also, we need a way for users to remove their photo from their profile. Suggest a small remove button below the photo which simple removes it.

Authorization redirects to the login page when the user is not logged in.

Should the user be redirected back to the authorization page once they've logged in or should the authorization page offer a sign in form?

This routine https://github.com/ninjablocks/douitsu/blob/master/lib/douitsu.js#L125-L133 assumes a lot of things.

Shouldn't we be using the url module?

Use an angular friendly drag drop file upload (eg https://github.com/danialfarid/angular-file-upload) as the current one (https://github.com/merty/simple-file-uploader) is jquery specific and isn't ideal.

Probably safest to just load gravatar images over https all the time.

Some of the text copy needs to change when switching themes. Is it possible to include a custom locales folder in the theme specification?

We need clarification on how gravatar should be integrated in the UI.

Just to cover ourselves if we upgrade and change the information provided by the /api/userinfo profile.

Move this to `/api/v1/userinfo'.

If a user authenticates from an app and each time they log out of the app, douitsu requires the user to approve trust again. The trust should be persistent. (ie: only prompt user once)

Additionally, the 'Your Applications' sections should list the trusted access tokens and enable the user to revoke it.

Check the following:

• DB Connection
• Redis Connection

I would prefer if applications where stored in their own table as it is a bit confusing at the moment.

i18next detects the language by getting it from navigator.language as the client-side does not have access to request headers. This works fine when the language is changed in Firefox but not in Chrome.

If it's not enough to rely on the default language set by the browser then it should be possible to set the language in i18next after calling a JSON endpoint on the server that returns the language set in the 'Accept-Language' request header.

one for user database owned by system => can create account
one for user database external => can't create account, only signin

Form validation needs stronger validation. For example, check for valid emails and strong passwords.

The profile returned to Passport is just an empty object.
It should be some details of the user record in douitsu.

Suggest:
{ nick, name, email, confirmed, image }

In the oauth2 routes section you have two routes see https://github.com/ninjablocks/douitsu/blob/master/lib/oauth2-routes.js#L63-L64

Github has the following URL https://github.com/login/oauth/authorize

The thing here is that our current route name implies that only dialogues will be shown by this route, which is not the case if the user has already trusted the application see #11.

Session data (e.g. transactions by oauth2rize are saved in session) needs saving to redis otherwise app will not work across multiple instances.

Is there a feature flag to turn on/off gravatar in the system?

/confirm/XXXX

Getting a 404 at the moment, need to review the nginx logs to find out what is working.