On 06/20/2012 10:07 AM, Ben Sizer wrote:
I have set up my Session object the usual way, via a session factory, etc.

SessionAuthenticationPolicy looks like exactly what I need, but are
there any examples of its use? It would be handy to know where it pulls
userids from, for example. Also it seems to want to be reading and
writing auth values to the session itself, so does that affect how I
have mark a user as logged in?

See the "callback" argument to its constructor. It's meant to be a function that accepts a user id and returns one of:

- A sequence of group ids

- An empty sequence (no groups associated with the user)

- None

If it returns None, it means that the userid doesn't exist in the database. If it returns a sequence (either empty or populated), it means the user exists in the database.

How you implement the callback is up to you. If you don't implement the callback, the userid is taken from the session without any checking.

See either of the two tutorials in http://docs.pylonsproject.org/projects/pyramid_tutorials/en/latest/wiki_tutorials.html for examples of how Pyramid security works. It's irrelevant which authentication policy is in use, all of them work more or less the same.

http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/auth/wiki2_auth.html has a more detailed description of how security works in the wiki2 tutorial.

I'd also like to know whether there is any support for getting an
automatically populated User object, eg. "request.current_user",
although if necessary I'm happy to do this manually in each view.

http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/auth/user_object.html


--
Ben Sizer




On Wednesday, 20 June 2012 06:04:00 UTC+1, Michael Merickel wrote:

    In the event that your Session object you keep referring to isn't
    integrated into Pyramid's `request.session`, then a) you should look
    into doing that (link below) and then use the
    SessionAuthenticationPolicy as Chris suggested or b) you should just
    write your own authentication policy that uses your Session object.

    
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/sessions.html#creating-your-own-session-factory
    
<http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/sessions.html#creating-your-own-session-factory>


    On Tue, Jun 19, 2012 at 8:18 PM, Chris McDonough <[email protected]
    <mailto:[email protected]>> wrote:
     > On 06/19/2012 08:38 PM, Ben Sizer wrote:
     >>
     >> I have written my own Session object, based on the example
    Pyramid 1.3
     >> provides, but with my own persistence mechanism - all well and
    good (I
     >> think). In the cookie I store a key into my database, so that I can
     >> retrieve persistent session info.
     >>
     >> Now I'd like to implement authorization, so that I can show
    different
     >> content to different authenticated users. So I looked at the
     >> authentication policy docs and then at the
    AuthTktAuthenticationPolicy
     >> and associated classes. They appear to also read and write a
    cookie,
     >> and it seems like there is a large amount of overlap with the
    session
     >> code. It's not clear if the two peacefully co-exist, or whether
    they
     >> should be rolled into one object.
     >>
     >> I figure I can use different cookie names in each case, but it
    seems
     >> to be duplicating effort and increasing the chance of bugs, eg.
    if one
     >> cookie expires when the other is valid, etc. I had imagined that I
     >> would have 1 session object, linked to a single cookie. That
    session
     >> would have a current_user() method or similar which would
    retrieve the
     >> user from the database, based on a user ID stored in the session.
     >>
     >> Basically, I don't know how to use these 2 things together - the
    doc
     >> page on Sessions has nothing to say about auth or about security
     >> (apart from the warning about the unencrypted session type) and the
     >> page on Security says nothing about sessions. I could probably
    write
     >> my own AuthenticationPolicy that queries my Session object but that
     >> would involve it setting cookie headers which would interfere with
     >> that Session.
     >>
     >> How should I proceed?
     >
     >
     > You can probably just reuse the existing
    SessionAuthenticationPolicy here:
     >
     >
    
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/api/authentication.html#pyramid.authentication.SessionAuthenticationPolicy
    
<http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/api/authentication.html#pyramid.authentication.SessionAuthenticationPolicy>

     >
     > - C
     >
     >
     > --
     > You received this message because you are subscribed to the
    Google Groups
     > "pylons-discuss" group.
     > To post to this group, send email to
    [email protected]
    <mailto:[email protected]>.
     > To unsubscribe from this group, send email to
     > [email protected]
    <mailto:pylons-discuss%[email protected]>.
     > For more options, visit this group at
     > http://groups.google.com/group/pylons-discuss?hl=en
    <http://groups.google.com/group/pylons-discuss?hl=en>.
     >

--
You received this message because you are subscribed to the Google
Groups "pylons-discuss" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/-I5cRbkh8i0J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.

--
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to