Current state of Authentication?

[Tyler Renelle]

Question for Nate / Brian. It seems sessions work was done in 0.3.12 to prepare for authentication, but that authentication as such isn't yet available. I know Carl-Johan Blomqvist took a stab at implementing password authentication, but that there were some sessions limitations preventing completion. I'm wondering

1. Is authentication actually currently being worked on, or is it still a future goal?
2. If auth isn't being worked on, are sessions mature enough that we can build an auth example (maybe on the recent TodoMVC), or are there issues still before auth is viable?
3. Is Everyauth being integrated currently, or is that a future goal?

I guess I'm wondering: how much auth is actually under development. If it's almost done, we'll hang tight - if none at all, we'll dive in. Minimize toe-stepping & effort duplication, etc.

[Nate Smith]

Auth is basically done and integrated with Everyauth. We just don't have an example yet. I'm kinda hosed for the next couple of weeks, but coming soon.

- Nate

[Tyler Renelle]

Thanks Nate!

[Tyler Renelle]

My friends, I present to you - Authentication! See my auth.coffee example of habitrpg. It's presently convoluted and a tad buggy (my own code's fault, not Derby). So stay tuned for much cleanup, as well as a forked derby-examples/chat where I hope to implement a generalized Everyauth example.

[Tyler Renelle]

Sorry, that's https://github.com/lefnire/habitrpg/blob/master/src/server/auth.coffee

[Juzer Ali]

Check out my implementation of authentication too. https://github.com/juzerali/derby-examples/tree/master/authentication

It isn't an app. Just a hacky, ugly looking page which fetches your fb data in displays on the same page. I did it basically by binding the everyauth.user object to "_user" model path. I haven't used derby's session variable yet so querying is not possible without passing the model.get("_user.id") to the query as arguments.

Also deployed at derby-auth.jit.su but not working. I am trying to make it work. You should check back in some time.

[Nate Smith]

Hey Tyler,

Thanks a ton for working on this! Sorry, I was occupied this weekend and haven't had a chance to review the code yet.

Very exciting to see a live app with auth support. Let's work together on docs and a simple example app to help others get started.

- Nate

[Tyler Renelle]

Sounds like a plan! Will be available later in the week or over the weekend. IMO, Chat or TodoMVC would be good for forking - thoughts?

[Tyler Renelle]

Also, note about habitrpg auth. You can use habitrpg without authenticating as a "sandbox" account (play with the app), then when you signup via facebook it makes that currently sandboxed account permanent via everyauth. Does this sound like a reasonable way to demo auth on Chat/TodoMVC, or should it be more traditional?

[László Bácsi]

Awesome work, Tyler. It helped me finish implementing authentication for bibliaolvaso.hu. Here is my approach: https://gist.github.com/3758734

The main difference is that I access MongoDB using mongoskin (bypassing racer) in findOrCreateUser. This will only run on the server anyway and the approach helps in avoiding security issues. However, in findUserById I use racer because that will make _user available to all routes downstream. This also gives me a clear point where I can setup new users and ensure they have all the properties they need.

LacKac

[Juzer Ali]

Hi Tyler,

I tried to implement habitrpg style authentication in my project. But I get error

TypeError: Object #<Object> has no method 'on'

    at Object.sessionMiddleware [as handle] (/home/juzer/Desktop/ican.vc/node_modules/derby/node_modules/racer/lib/session/session.Store.js:108:8)

    at next (/home/juzer/Desktop/ican.vc/node_modules/express/node_modules/connect/lib/proto.js:190:15)

    at store.get.next (/home/juzer/Desktop/ican.vc/node_modules/express/node_modules/connect/lib/middleware/session.js:299:9)

    at /home/juzer/Desktop/ican.vc/node_modules/express/node_modules/connect/lib/middleware/session.js:316:9

    at /home/juzer/Desktop/ican.vc/node_modules/express/node_modules/connect/lib/middleware/session/memory.js:57:7

    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

                   ^

I wonder what I am doing wrong?

[Tyler Renelle]

Have a gist of the pertinent code?

[Tyler Renelle]

Hey Juzer, I'll start an example here: https://github.com/lefnire/derby-examples. Not quite there yet, but it's not crashing on start - take gander

[Tyler Renelle]

There we go, that auth example is a cleaner implementation to reference than habitrpg. I'll eventually get uname/pw login integration there, since that seems to be what most people want, but no time just yet.

[Darryl Ryan]

Woo, that works for me nicely, thanks!

I still need some help with the password auth though as you mention... I am not clear on how one goes about making server-only database calls and then stores the results in the shared session.

I seem to recall something about changing some setting so that only the database functions you explicity export can be called from the client side, but I can't find where it says that now, maybe I made that up? :P

[Juzer Ali]

Hi Tyler,

See my gist here https://gist.github.com/3938452

I am getting following error:

/home/juzer/Desktop/ican.vc/node_modules/derby/node_modules/racer/lib/session/session.Store.js:265

        , sess = self.sessions[sid];

                              ^

TypeError: Cannot read property 'll5ei9QvGOaHJ/Crtq5dqwlI' of undefined

    at sessStore.load.sessStore.get (/home/juzer/Desktop/ican.vc/node_modules/derby/node_modules/racer/lib/session/session.Store.js:265:31)

    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

If I uncomment .use(express.session()) i.e. when I use express session middleware as well, it works, but model.session is unavailable inside derby routes.

--
Regards,
Juzer Ali
--
http://about.me/juzerali

[Tyler Renelle]

@Juzer, if you can - I'd just start over on your auth code and copy-paste from derby-auth-example from above.

@Darryl - Just thinking out loud, might not work. user object looks like {…, auth: { facebook: {..}, login{nam: 'a', pass: 'a'} } } Could expose a query which verifies user exists with that name/pw, using similar setup as derby-auth-example, and returns something useful to work with.  But then you setup a readPathAccess which denies access to user.*.auth, so that when it's sent over the wire they don't get user.1.auth as part of the package. I think the query can bypass this readPathAccess?

[Ilkka Huotari]

Tyler,

Thanks for the derby-auth, it seems awesome.

However, I have the same problem as Juzer Ali did, the session isn't available at model.session when rendering at the client side.

Also, the examples didn't seem to address this issue? There is only one route, which gets rendered on the server side in practice, I think. https://github.com/lefnire/derby-auth/blob/master/example/lib/auth/index.js

So ... how to solve this one? How to get the session on the client side? One thing I noticed that sessionId is available through the page object (page.model.socket.socket.sessionId), maybe this could be of help.

[Tyler Renelle]

All the apps I've been building have been single-page apps, so this module might break down where multiple routes exist. I don't have any need for that myself, so someone will have to jump in on derby-auth & help out if possible.

[Ilkka Huotari]

Ok.

I feel that offering the session object on the client side is Derby's internal problem that Nate & Brian are going to work on -- or maybe they already are? 

Maybe this will raise some security issues too. 

I could make a dirty hack until the real solution will be in place.

[Daniel Saewitz]

I just ran into the same issue as Juzer and Ilkka. My current solution is to just check for the id at the beginning of every route (coffee):

  id = model.get('_user.id') || model.session?.userId 

  model.subscribe "users.#{id}", (err, user) ->

    model.setNull '_user', user.get()

Perhaps there's some way to set an express or socket.io middleware to set the _user model.

[Daniel Saewitz]

I've added an express middleware after the store and before the auth:

    

    .use(store.modelMiddleware())

    .use((req, res, next) ->

      model = req.getModel()

      model.subscribe "users.#{model.session.userId}", (err, user) ->

        if err then console.log err

        model.set '_user', user.get()

        next()

    )

Please tell me if this is wrong in any way, but it seems to work.

[Daniel Saewitz]

Note: it's probably better to use

model.ref '_user', user

On Monday, January 14, 2013 at 2:48 AM, Daniel Saewitz wrote:

model.set '_user', user.get()

[Ilkka Huotari]

Thanks Daniel,

Not sure if it's wrong, but that's what I'm using now too (getting the user/session from the model). 

[Ilkka Huotari]

A question to Tyler or anyone that would like to answer:

I'm fetching the users data from the DB (collection users, as that's what derby-auth is set to use), and I'm bumping into readPathAccess. 

The thing is that I would need some information on all the relevant users (for example if I make a "join" with a comments collection - or if I'm looking at some user's profile page and need that info). That is, I would need some read access to that user's data, even if it's not me. I could want the data from all the users.

That brings some problems, as some of the data probably isn't public. 

Am I right? How do we tackle this problem? (Did I explain this well enough?)

One suggestion could be:

Create two paths:

• users.*.private
• users.*.public

... and use readPathAccess only on the private path.

Any other solutions? Is this even a problem?

Thanks.

[Tyler Renelle]

derby-auth has a "customAccessControl" callback option which bypasses derby-auth's path accesses. You can see me using it in HabitRPG by declaring it here, and using it here. You'll want to just use custom logic in your access paths based on the requesting "captures". I went down the users.*.private/public rabbit hole for hours, and for reasons I can't remember right now - it doesn't work.

--
You received this message because you are subscribed to the Google Groups "Derby" group.
To unsubscribe from this group and stop receiving emails from it, send an email to derbyjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ilkka Huotari]

That seems to work, thanks, Tyler.

I originally thought that readPathAccess would kick in every time, with exposed queries (querymotifs). But no, they seem to affect only when querying paths directly. So I had a bit of confusion there. Works nicely now.

[Ilkka Huotari]

One thought; if/when the database references are introduced into Derby, we may have trouble with privacy issues again. That is, if the ref id points to the users collection, which has some private data...