prismatik / auth Goto Github PK

I think this service should accept an ENV var that will specify how many encryption cycles bcrypt should use.

Basically the problem is that production grade bcrypt takes quite a bit of time and it slows down tests significantly. I want to be able to specify something like ENCRYPT_CYCLES=1 in a test environment and make the auth service to create new records faster.

Also this will allow us to use more cycles in security critical apps

https://github.com/Prismatik/password

when the signIn fails due to a wrong username or wrong password, the response error actually says either wrong username or wrong password.

this is a security vulnerability. firstly it tells the attacker that they've got the username right. and secondly it allows the attacker to check your system against existing email databases and know who's actually registered in the system.

the failure message should just say 'wrong username or password'. don't even mention 'email'

you're throwing 403s instead of 401s

403 - means permission denied. which means a user authentication is valid, they just try to access something above their level, like admin features and such.

401 - means authentication failed or was not issued

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Should auth adhere to semver? So far, there have been some major releases with no change in versioning. As this service is now rolled out for multiple projects, this feels quite important.

It will give us the confidence to update without having to worry about projects breaking.

as per Prismatik/auth-driver#21

https://github.com/Prismatik/auth/blob/master/controllers/login.js returns a JWT keyed to the email. That's not particularly secure as it'll give you access to all future accounts that use that email address. Sessions should be tied to their related entities by id, i.e., users, so they're guaranteed to only apply to the user that created them. They should not be invalidated when a user changes her email address in the app.

the service is kinda slow in testing environment, needs some investigation

Hey,

authDriver.update(purchaser.customerId, {
    permissions: [{type: "purchaser", entity: purchaser.wholesaler}]
})

Lead to:

Unhandled rejection ReqlRuntimeError: Cannot convert `undefined` with r.expr() in:
r.table("entities").get("9b061055-e06a-460f-a068-370d54416af1")("rev").eq(undefined)
                                                                          ^^^^^^^^^

    at Term.run (/home/user/Documents/auth/node_modules/rethinkdbdash/lib/term.js:43:17)
    at Server.exports.validateEmail.exports.validateRevision.r.table.get.getField.eq.run.then (/home/user/Documents/auth/lib/entity.js:31:4)
    at next (/home/user/Documents/auth/node_modules/restify/lib/server.js:906:30)
    at f (/home/user/Documents/auth/node_modules/restify/node_modules/once/once.js:17:25)
    at Server.exports.validateEmail.query.isEmpty.run.then (/home/user/Documents/auth/lib/entity.js:9:23)
    at next (/home/user/Documents/auth/node_modules/restify/lib/server.js:906:30)
    at f (/home/user/Documents/auth/node_modules/restify/node_modules/once/once.js:17:25)
    at Server.module.exports (/home/user/Documents/auth/routes/middleware/basic_auth.js:8:10)
    at next (/home/user/Documents/auth/node_modules/restify/lib/server.js:906:30)
    at f (/home/user/Documents/auth/node_modules/restify/node_modules/once/once.js:17:25)
    at parseJson (/home/user/Documents/auth/node_modules/restify/lib/plugins/json_body_parser.js:65:9)
    at Server.parseBody (/home/user/Documents/auth/node_modules/restify/lib/plugins/body_parser.js:90:13)
    at next (/home/user/Documents/auth/node_modules/restify/lib/server.js:906:30)
    at f (/home/user/Documents/auth/node_modules/restify/node_modules/once/once.js:17:25)
    at IncomingMessage.done (/home/user/Documents/auth/node_modules/restify/lib/plugins/body_reader.js:121:13)
    at IncomingMessage.g (events.js:260:16)
    at emitNone (events.js:67:13)
    at IncomingMessage.emit (events.js:166:7)
    at endReadableNT (_stream_readable.js:905:12)
    at doNTCallback2 (node.js:441:9)
    at process._tickDomainCallback (node.js:396:17)

I might be doing something wrong, too, but given that the request will then timeout with no 500 returned, it's a bug. ;)

Getting stuff like this:

 permissions:
   [ { entity: 'dd36730e-f449-4e24-9854-90905c7757f9',
       type: 'purchaser' },
     { entity: '31ba0784-2e6b-4679-86c1-320802d02fa2',
       type: 'purchase' },
     { entity: '31ba0784-2e6b-4679-86c1-320802d02fa2',
       type: 'purchase' },
     { entity: '31ba0784-2e6b-4679-86c1-320802d02fa2',
       type: 'purchase' },
     { entity: '31ba0784-2e6b-4679-86c1-320802d02fa2',
       type: 'purchase' } ],
  rev: 'fac9c07e-6ee7-4e34-8d3e-4357e24532df',
  updated_at: '2015-12-24T06:13:51.658Z' }

Should be a way to compact the dups.

Given my initial argument list:

• Development overhead dealing with too many services.
• Development overhead dealing with another model structure and its marshalling.
• Runtime overhead of making remote requests. Especially text-based HTTP.
• Runtime dependency on another service that isn't the database.
• Making a service out of something that I see little benefit in being a service.
• 2nd system syndrome
• Different databases and services complicating testing.
• Different databases and services slowing down testing.

I've elaborated a few:

1. SOA can be argued for when one's dealing with possibilities of graceful degradation. Majority of systems (incl. Ordermentum) depend on AA (authentication+authorization) to the extent that they can't run without it. No resilience advantages with separation.
2. Overhead of change management. Services can't be versioned nor backtracked from an upgrade as easily libraries. Having two services that need to be deployed at the same time is not SOA. It's premature extraction. Adding backwards compatibility for asynchronous upgrades is a lot of work better spent elsewhere. Note: "changes" include the data and its meaning to the system in the service and its database, not only improvements to the former's code. Related anecdote: I have an app that people have open in their tabs for weeks. It's no duck soup to ensure people's data doesn't get lost over backend upgrades. ;-)
3. AFAI've understood, there's a possibility of requesting an array of sorts from the service to make decisions on. That's tighter coupling between the permissions structure and the app than a mere boolean-returning request. How does the code related to making boolean requests, let alone more complex ones, get to the app? From a shared library? Where's then the benefit of an intermediary HTTP layer over bundling everything to said library?
4. From the fact that a library requires its own database, it does not follow that the right or sustainable solution is to have another service present its contents. The new database, by extension of its front-end, becomes a dependency of the system. Adding an intermediary service doesn't reduce that.
5. There are better approaches to extracting out auxiliary services than having them depend on shared (permission) semantics. E.g. tokens. See Amazon S3's implementation for one approach.

Create a library, have it return an instance of Auth given database connection details and call it a day. ;-)

Tests seem to hang until you ctrl-c outta there.

https://github.com/Prismatik/auth/blob/master/controllers/entities.js#L14

I think that should be a POST. At no time do we accept a user persisting an inherited_permissions array, for example. In order to satisfy the semantic requirements of PUT we would need to store the resource exactly as the user had sent it.