Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication and authorization #268

Closed
coyotespike opened this issue Sep 18, 2016 · 4 comments
Closed

Authentication and authorization #268

coyotespike opened this issue Sep 18, 2016 · 4 comments

Comments

@coyotespike
Copy link

coyotespike commented Sep 18, 2016

I've read all the discussions in the issues about authorization and authentication. Here's my current understanding.

  1. To authenticate and authorize at a basic level, all we need is a way for the
    server to identify uniquely a client which has passed the login test.
  2. A crude form of authentication can be accomplished client-side alone by setting a logged-in
    flag. This is vulnerable to client-side manipulation and is not a true
    authentication procedure.
  3. Authentication can also be accomplished via the :uid tag by which Sente
    identifies a client to enable server-side pushing. After authentication,
    simply set the :uid tag.
  4. This simple method uses the :uid for two purposes, which is efficient. Thereafter Sente checks for the :uid anyway. However this method doesn't allow token timeout, and the Buddy
    library expects the token to live in :identity.
  5. It's not clearly to me whether the token associated with :identity or with
    :uid should be encrypted in some special way. If not we are essentially
    checking for the mere existence of the token, whatever it is.
  6. If we use the Buddy library's approach and use :identity then we also get the Buddy
    functions. As long as Sente passes the normal Ring session back and forth over the web sockets,
    then we can set and pass tokens on client and server sides in the normal
    Buddy way. It seems this is preferable to duplicating security functionality
    to work with Sente. And this is why Sente is or can be orthogonal to Buddy/Friend.

How does that sound, especially 5?

One more follow up question.

In #173 it's pointed out that we can use a params option when creating a channel socket. If I use that, should I be starting the router with the :params option, sending my authorization request, and then close the router?

I would then run (sente/start-chsk-router! ch-chsk event-msg-handler*) again for a specific future request, without the :params.

@coyotespike
Copy link
Author

coyotespike commented Sep 18, 2016

For easy reference, here are other issues addressing the topic.
#173 -- On setting headers
#234 -- User-Ids described and clarified
#17 -- Logon/Logoff Example
#172 -- Guidance for Closing an Unauthorized Connection

@arichiardi
Copy link
Collaborator

Oh nice, it would be great to add them to the README ;)

@ptaoussanis
Copy link
Member

Have just setup a basic wiki where we can maybe start collecting together info like this from users?

Please feel free to move/add anything there that you think others might find handy. And that way no need to wait for me to merge, etc.

Cheers :-)

@theronic
Copy link

theronic commented Jan 20, 2018

I read through all of the suggested docs and I still don't understand how I should handle authentication, what the lifecycle for uid/sessions are and during what event I should assign or check them. Do I need to wrap sente routes with wrap-session middleware?

Is there a full example somewhere? Would appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants