d40cht
commented
11 years ago OK. OAuth is straightforward. Scentry etc. in Scalatra looks more complicated and not that well documented. Some clues here:
https://groups.google.com/forum/#!msg/scalatra-user/-E6rGV_8N9c/hC4sIKe47qMJ
Extract:
There are many questions in your email I'll try to address as many as possible. First off scentry is written with only http in mind so you can have multiple authentication strategies for different parts in your app. It needs access to the httprequest because it needs the session id.
Scentry is basically this: https://github.com/hassox/warden but scopes haven't been implemented I think.
The scentry object is instantiated once for every request. The scentry object itself is the engine for scentry. it keeps a registry of strategies and will invoke the correct methods on those strategies at correct times. A strategy is merely a set of hooks in the lifecycle of the authentication process.
The app a strategy refers to is a scalatra kernel. it needs that to be able to use the http methods and figure out if it should run or not. The main idea is that you can register multiple strategies and based on the content of the request you can choose different ways to get the user model back for the stored id.
The user object that a strategy and scentry are bound to are basically your own user model. There is a toSession method and fromSession method that need to be implemented and they typically get an id out of the http session store and fetch a user with that. That user is then available in the user method on the scalatra kernel object (your servlet)
When a request arrives it gets processed by scentry by checking the isValid method, if a strategy applies then it will execute the authenticate method of the winning strategy. when that authenticate method succeeds the afterAuthenticate method is executed and by default the toSession(user) method is then called to store the user id in the auth store, which by default is the httpsession store. But there is also a cookie store available one that uses httpOnly cookies and one that uses plain cookies also accessible by javascript. After adding the user to the authentication store it will call afterSetUser in which you can then use the app to set headers etc as are needed for Basic Auth.
But auth with websockets using scentry I don't know how that is going to work. you can potentially do auth with websockets over header/basic auth during the handshake after that a websocket has nothing to do with the http server part anymore they are a totally separate story. If you're using atmosphere with scalatra then you have access to the request and you can use scentry. The approach you mentioned in IRC where you generate a unique token in the page and then send that is basically the one we're using too.
I think with a bit of effort it could be made request agnostic and then it should be possible to use scentry outside the scope of a web request; but without modifications to scentry I don't see that happening.
I hope this answers your questions if not, keep sending eventually this will then make it into the book or something
Against Google/Facebook user accounts
Login local cache to include user details, ip of client and an expiry time.
An appropriate simple Scentry example: https://gist.github.com/casualjim/4400115