accounts-js / accounts Goto Github PK

I just stumbled on this repo while looking for an account management library for a project. I really like the idea of having all of this effort of setting up authentication being handled by a library.

Now I've seen that this is under heavy development and was wondering if there's a time-line or an agenda what needs to be done / is the most urgent since I would love to contribute to this project!

Thanks in advance!

// edit just noted that this is similar to #20 . Maybe setup some projects in github to make things clear?

@gadicc What are your thoughts on using Waterline for our database code? This would allow us to forgo writing individual database adaptor packages like we had planned. Instead defining a model for our accounts data and relying on the end user to install the necessary waterline adaptor package for their database.

On the flip side, this would be putting all our eggs in one basket.

I'm leaning towards our original approach.

Immutable js forces the use of state.get and state.set, we can achieve the same thing with destructuring without making the store mixing Map and Objects right?

Let's rename to follow the following scheme.

@accounts/accounts
@accounts/graphql
@accounts/rest
@accounts/react
@accounts/react-material-ui
@accounts/sql
@accounts/mongo

The organization can be changed to js-accounts.

Hi! I'm creating a small framework on top of apollo, express, mongodb, and react/redux and I wanted to know how difficult it would be, considering the actual stage of the project, to achieve mechanisms such as

• providers auth
• token expiration and refresh
• password update
• providers linking

The code underneath AccountsClient.ui.config can be improved. The provided options object provided as an argument needs to be validated to make sure the user is setting valid keys and values.

Also, write tests :)

The following should be implemented, additional details can be found here http://docs.meteor.com/api/passwords.html.

An important detail to note in the email implementation is that should be generic enough for consumers to plugin their own email service. For example using the mailgun api vs using their own smtp server.

Server

• addEmail
• removeEmail
• sendResetPasswordEmail
• sendEnrollmentEmail
• sendVerificationEmail
• resetPassword
• sendWelcomeEmail

Server config

• sendVerificationEmail (default false)
• sendEnrollmentEmail (default false)
• sendWelcomeEmail (default false)
• email template for each email type, consider using https://github.com/mjmlio/mjml

Client

• requestPasswordReset
• requestVerificationEmail

Client config

• onResetPasswordLink
• onEnrollmentLink
• onEmailVerificationLink

Currently the apollo-errors package is being consumed by our custom AccountsError class to throw errors. Moving forward we can continue using apollo-errors or make our own custom error class. The reason behind using apollo-errors is that it allows errors to carry more data than just an error message, this is particularly useful in the case of validation errors where you want to associate errors with certain fields. Furthermore this allows http status codes to be sent along side the message, rather than within it.

The other packages that consume @accounts/accounts: rest-api, rest, react and the db interfaces will also need their error handling code to be updated as part of this issue.

This should be done in all the relevant repos too.

Can you guys consider adding something like:
https://github.com/gwendall/meteor-impersonate

to the accounts library, as an option flag or some such? Or any other way that an administrator might be able to “become” a user without knowing their password, as it helps so much when trying to administrate a large application used by lots of users.

https://github.com/simov/grant

Create an eslint package to share a common config between the differents repositories. Right now each packages have a different lint config and it's hard to keep all packages synced at the same time.

What is everyone's thoughts on having this package (and the rest of the packages) automatically publish to npm whenever new code comes into master? I think this can be setup in the circle config.

This library is using the localStorage to store the JWT. This makes it accessible to the JS-Enviroment and therefore vulnerable to XSS-Attacks. A good alternative, that prevents this flaw is to use a cookie that is httpOnly.

Ressources on this problem:

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS.

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

"Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the httpOnly flag."

To make the claims available to the client, they should be sent seperately, but the whole JWT should not be available to the JS-Enviroment

Right now here we export the all user object so the bcrypt token etc are sent back to the user.

We accumulate here all work need to do in order to change our current code base into what was created on https://github.com/js-accounts/next

Tasks:

Migrate all repositories to TS

• accounts/server #108
• accounts/client #108
• accounts/common #108
• accounts/mongo accounts-js/mongo#25
• accounts/rest-express accounts-js/rest#26
• accounts/rest-client accounts-js/rest#26
• accounts/graphql-client accounts-js/graphql#14
• accounts/graphql-api accounts-js/graphql#14
• accounts/meteor-adapter

Add new libraries

• accounts/oauth - WIP #112
• accounts/password - WIP #112

Refactor existing libraries

• accounts/rest-express
• accounts/common
• accounts/server
• accounts/mongo

Docs

• Update the docs

Not sure if it's the best approach, since it's hard to debug, and the app that uses these packages should minify it's own code and it's dependencies...

@TimMikeladze what do you think?

Setup Lerna . This task needs to be completed before an official release of the packages.

I suspect the repos and packages will look like this:

accounts

• @accounts/core
• @accounts/client
• @accounts/server

rest

• @accounts/rest-client
• @accounts/rest-express
• @accounts/rest-koa
• @accounts/rest-hapi

graphql

• @accounts/graphql-client
• @accounts/graphql-express
• @accounts/graphql-koa
• @accounts/graphql-hapi

react

• @accounts/react
• @accounts/react-material-ui

@gadicc What are you thinking our approach should be for documentation?

I'm thinking we could standup a static site similar to http://dev.apollodata.com/tools/

• Use immutable inside accounts reducer
• Document usage with custom redux store

This way, you could be able to register for those hooks, remove your registration when no longer needed, and create these dynamically.
This way, we can also allow multiple subscribers to the same hook.
Maybe also consider to use EventEmitter and trigger the hooks with emit ?

Something like that:

AccountsClient.config(...);

// later in your code
const stopFucntion = AccountClient.onUserCreated(() => {

});

// And when you no longer need it
stopFucntion();

@TimMikeladze @davidyaha @pradel what do you think?

@TimMikeladze, ok wow, think that's everything! Latest version of all packages; everything we'll need, babel, eslint, coveralls, mocha, etc, etc. I should make a repo just for all that :> CircleCI & coveralls all setup and working (ignore the "coverage unknown" on the README, github caches too aggressively - you can click on it for the coveralls page).

Client

As discussed this is a fullstack package. That's my preference but it's not a huge issue for me to split back to two packages if it feels uncomfortable (I do think one is simpler though for both us and users). The imports would be:

// Server
import Accounts from "graphql-accounts";

// Client
import Accounts from "graphql-acounts/lib/client";

babelrc

Uses es2015-node4 preset for the server (using native generators) since even Meteor uses that now. Client uses es2015 and regenerator. Added async plugins and object-rest-spread.

Our names

I just went alphabetical for README, LICENSE, package.json. Hope that's ok :)

eslint

Using the defaults. If we come across anything that's uncomfortable, we can probably just change it (but let's disable specific rules inline as a preference whenever possible). I thiiiink the async/await stuff is all included as part of babel-eslint but let me know if anything's not working.

testing

As discussed, tests are adjacent to source with a .spec.js extension. I included a sample file with all the utils we'll need (sinon, chai-as-promised). You said you were ok with should vs expect. I definitely prefer that but I feel it's personal and that maybe expect might be better for lots of collaboration. All it really boils down to is that since should works on objects, the syntax gets more awkward for checking null and undefined.

something.should.exist();       // throws otherwise & blocks other assertions in same it()
something.should.not.exist();   // apparently works in async callbacks in node
should.not.exist(something);    // guaranteed to work for null or undefined
should.equal(something, null);  // guaranteed check for null specifically

I don't usually include IDE/editor configs etc but I included a wallaby.js since it's really awesome and if you don't use it yet you should try it it will change your life :) And encourages more attention to tests, etc.

Let me know if you have any comments or if anything goes wrong during use.

Allow for single app store to be created outside of the accounts package.

A user should be able to change his password by passing is old and new password.

A user should be able to:

• See their logged in devices and revoke specific tokens
• See linked services and disassociate them individually
• Link new services where email doesn't match (otherwise should be auto on login)

Currently if you look at 0.0.13 the onResumedSessionHook is in lib-es6 but not in lib, meaning somewhere in the build process something went wrong.

Rebuilding off of master gives the correct results with the new code being in both.
Could be a variety of errors, but putting the issue up here for visibility.

Best solution imo would be to recompile and deploy bumped version to npm to get a good release out, and then look into the build issues as time allows.

Thanks guys. Cool library.

@davidyaha @TimMikeladze

Per discussion with @davidyaha, this set of packages could benefit from a typing system since we're defining interfaces for communication between packages.

Flow and Typescript are the two options. I like Flow in favor of Typescript because of the minimal buy in, you can continue using the current build setup which is more familiar for JS developers not familiar with Typescript. On the other hand, Typescript has been gaining a considerable amount of adoption in the community but does have a more involved configuration.

For example: the app is loaded, and called resumeSession - the tokens were fetched from the storage and now it being validated, during this time, does isLoggingIn should be set to true?

Create an audit system that uses a given "Logger" interface to report regular logins and more importantly login and auth errors.

We would like to support a way to extend that with authorization layer when implemented so we should keep that in mind.

Would be great to replace the generated organization avatar with something relevant.

In Meteor's accounts system the configuration for each service (keys, login style, etc) is stored in the database. @gadicc I see similar approach in your DBDriver interface with the fetchConfig function.

Using Grant the services are configured through JS/JSON and the data probably originates from environment variables.

My question is which implementation to go with? Or perhaps a hybrid of the two?

What are the benefits of storing the service config in the database?

Flow is nice but Typescript provides a better development experience.

The following config options have been implemented

• title
• requestPermissions
• requestOfflineToken
• forceApprovalPrompt
• requireEmailVerification
• passwordSignupFields
• minimumPasswordLength
• loginPath
• signupPath
• resetPasswordPath
• profilePath
• changePasswordPath
• homePath
• onSubmitHook
• onPreSignUpHook
• onPostSIgnUpHook
• onEnrollAccountHook
• onResetPasswordHook
• onVerifyEmailHook
• onSignedInHook
• onSignedOutHook
• sendVerificationEmail
• forbidClientAccountCreation
• restrictCreationByEmailDomain
• loginExpirationInDays
• oauthSecretKey
• passwordResetTokenExpirationInDays
• passwordEnrollTokenExpirationInDays

The lifespan of expired sessions should be configurable. It can provide a useful log for user account activity. Keep the latest 10 sessions for example.

Per discussion with @davidyaha in #72

At the moment the validation rules for each field (username, password, email) are handled within validators.js in the @accounts/common. These should be configurable via the accounts config so consumers could define their own validation rules for fields.

The default password field validators should also take into account the minimum password length requirements.

Thoughts on validating password complexity?

I've been playing with apollo-passport some time ago, and was waiting for it to become "production" ready. Now I see that it has been replaced by js-accounts.

What's the current state of this project? Can I install packages and get a working proof of concept, or is it to early for that?

I've seen the readme of course, but that one doesn't really have any information in it yet.

I don't want to rush you, just a big fan and waiting for a project like this to become useful. Something like "Meteor accounts" outside of meteor would be awesome. ❤️

Thanks for your great work!

On the client calling loginWithPassword should return LoginReturnType

@davidyaha per our discussion in slack

The https://github.com/auth0/node-jsonwebtoken package has dependencies on the net and dns modules which aren't available on the client. This presents a problem since this is a repo publishing both client and server code in a single package.

Currently the work around is to mock them in the consuming app's webpack config as seen below.

node: {
    net: 'mock',
    dns: 'mock',
  },

The simple solution is to provide these mocks within the core accounts package if running on the browser.

Define a map that has an error code mapped to an object that holds technicalMessage and humanizedMessage to be used on view layer packages.

This library should have an option for permanent sessions/ a "remember me" function.

Security advice on this:

http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website

Hi again,

I was wondering if you were thinking of integrating something like redux-auth-wrapper which is a really nice HOC from @mjrussell that integrates well with react-router (and react-router-redux as shown here) or if you had something else in mind for authorisation?

Cheers,

Jun

Hey guys this is awesome. What's the state of this project? Can't yet install via npm install @accounts... Would be interested in implementing a MERN integration (see my motivation here) so if you are serious about maintaining this let me know!

Allow the user to login as a temporary guest account. This should be configurable in config.

Per #21

The existing build and code should be reconfigured to use flow.

@TimMikeladze, I really want to help but I'm not sure yet where to jump in... Could I ask for:

1. A general update. What's done and what you're busy working on now, where you'd like help / what's important but you're not currently working on.

2. It sounds from the other issue that maybe you're already using this with one of your sites... how does one get started? Could you post some basic setup notes?

I noticed also that you're using REST for a lot of stuff (vs GraphQL). I actually think this is the way to go, for now at least. Firstly, since we need control over incoming requests anyway for the popup auth flow, but also, since it's incredibly unpleasant to setup Apollo atm with multiple sources for schemas. Even though I had a working (but ugly) workaround in my meteor and saturn starters, this was the thing I was most worried about and the most complicated to set up. I'd say for this particular project REST is a better fit at this stage.

Useful for checking a non-admin's user experience. Should:

• Be disabled by default
• Require an explicit user-provided access check function to enable
• Possibly not rely on JWT and do an explicit access check at request time
• Keep track of original user on the client, with UI hint to switch back
• Keep track of original user in context, for logging purposes