On 05/08/2014 04:42 PM, Jonathan Vanasco wrote:
On Thursday, May 8, 2014 1:40:58 PM UTC-4, Chris McDonough wrote:
I'd be surprised. That'd presume the two implementations stored
data in
the exact same way, which might well be the case, but can't be assumed.
If it didn't break, it'd only be by happy accident.
agreed. most just pickle a dict. a few wrap the dict in something.
but most just pickle a dict and have internal '__' prefixed fields
By "most" I assume you mean Beaker, because pyramid_redis_sessions
doesn't put any __ prefixed fields into its session data. There's no
guarantee about any of that stuff, it's 100% implementation dependent.
The other topic, at this point, is making it possible to uniformly
parse
the session id out of the session cookie?
For the sake of clarity:
- The other topic is to tie the "session's cookie" to the "session
object" itself.
- This would have the benefit of *potentially* making it possible to
parse the session_id out of the cookie. That would take additional
development effort by the end consumer, as different session schemes
encode the session id in a cookie differently. Depending on the scheme,
this might not be easy/possible.
- This would not be as convenient as being able to access a session_id,
but it would allow for actual sessions to be identified and trackable
and provide for accountability in testing.
- This would remove the "black box magic" of the current API, where it
is impossible to accurately tell where / how a session was created.
I understand this to mean (from your earlier emails, you don't expressly
say it above) that you want to be sure that there is a existing session
that has the id "123" if you parse "123" out of the cookie. Since we
can't stop browsers from sending cookie data, and since sessions have a
timeout (and as a result even a valid session id might not resolve to a
non-new session), I don't see how it would be possible to make that
promise due to the way the web works. The only implementation that
would have a shot at it would be purely cookie-value-based sessions,
because the value is stored in the cookie itself.
If that's not what you mean, can you explain the difference between what
you're asking for and "I want to be able to get the session id using
only request data, without loading the session"? Having an .id on
session objects would not help with that at all, AFAICT.
In any case, wrt black box magic, I'm sure you understand that the point
of an interface is to create a black box, such that one box can be
swapped for another by otherwise unconcerned consumers without the
consumer needing to open either box. Once you start dithering in the
interface definition about what's expected of implementations, it's
understandable that those implementations aren't going to be able to
satisfy the intent of the interface. In general, "optional" APIs, APIs
which are permitted to raise a NotImplemented exception or APIs which
return a "sorry Dave I can't do that" sentinel are usually indicators of
an interface that isn't very well defined. I know this because I've
perpetrated plenty in my time.
I'm still not sure how that would actually help you as much as you
think
it would, given that if you change the session implementation, you will
already necessarily need to change code, or at least there's no
guarantee that things will "just work" when you swap in a random
session
implementation given your description of the cases you want to support.
In the meantime, I'm pretty loath to make "interface suggestions": APIs
are really where the rubber meets the road. It's either in the
interface or it's not, and I'm leaning towards not.
I get that. And I don't expect to sway you on this. But this is where
Mike and I bring up that pesky point that all server side sessions
feature this... somehow.
Without any guidance, they're implemented differently. The needs to
access this id may be specialized, but are common enough.
Instead of standardizing how a common feature / implementation detail
takes place, things are left to be wild.
The "Pro" of supporting an official API point is that developers would
have guidance and something to write upon. There would be some sort of
consistency that leads to higher interoperability.
The "Cons" seem to be focus on:
- Potential issues/constraints that future session developers might
encounter
- The potential to return "None" (or raise a NotImplementedError) if an
application developer accesses this in an unsupported environment.
The first argument is very weak to me, especially on the benefit. It
seems be a theoretical issue, not a practical one.
I still simply don't understand any use cases where the second argument
would actually be a problem. That wouldn't be much different from
someone trying to commit a transaction in a transactionless environment.
Committing a transaction doesn't return a value. The person doing the
committing doesn't need to inspect the return value of a call which
commits a transaction, so committing a transaction in a transactionless
system can be a noop; something called purely for its side effects
(which may be no side effects at all). Asking for a session id and
getting back None is a different, because the caller cares deeply about
the return value; he wouldn't ask for it if he weren't going to use it
for something.
Since I already wrote down the problems with the value sometimes being
None I won't bore you with them again, but note that this example gets
to the crux of the issue. If you need to access the "real" session id
(as opposed to some UUID stored inside session data), it necessarily
means you intend to do something useful with it. There are currently no
APIs in Pyramid that allow you to do anything useful with it at all, so
by definition you're always going to use it "behind the back" of any
interface. Even if you just log it, presumably the reason you care
deeply that it's the "real" session id is to be able to later make some
sort of postmortem query of the session storage to debug something,
right? Otherwise you wouldn't much care about it being the same key as
the key used by the backing store, and you could just use a UUID stored
as session data.
I don't care at all if you use the "real" session id for whatever you
like, it's totally fine by me. But I can't wrap my brain around why
it's such a burden to need to depend on session plugin implementation
details to get the "real" session id and it's seemingly such a lesser
burden to do need to depend on those same plugin implementation details
to do something useful with that same session id. If the argument,
instead, was "I want to be able to load session data using an arbitrary
session id via a well-defined interface so I don't have to go look at
any implementation details", I'd understand. But nobody has asked for
that so far. Is it because it seems like a bridge too far, or what?
To truly avoid you needing to read any plugin code, we'd need session
add-ons to provide implementations for APIs like I described in my last
emails to Mike:
def session_id_from_request(request):
""" Return the session id of the current request """
def load_session(request, session_id):
""" Return the session object given the provided session id """
That doesn't mean that you are out of luck, though. Have you
thought of
this? It would require that you change code when you change session
implementations, but you already have to do that anyway.
i think we used a NewRequest subscriber to map a session_id attribute
onto the session. I'd have to dig into code.
FWIW, this means that each request, even one for a static resource like
an image or a JS file, is potentially creating a (or at least
deserializing an existing) session object. This is almost sure to be a
bottleneck and may be slowing down your app by an order of magnitude or
two. Deferring until the session is accessed via its factory (when
request.session is accessed) prevents this from happening, so it's
probably better to do it that way.
we run `request.session` and `request.session_https` ; this allows https
calls to read/set the non-https session data. a client side cookie
would never interact with a session_id, so that functionality is not needed.
Also, the biggest problem of your approach -- and mine -- isn't that I
need to update my code. It's that I need to go through all of the
session plugin's code to figure out how the key is being managed. i
end up reinventing the wheel a lot on this; as does mike. i'm sure
others do too. instead of doing all these one-off fixes, i'd rather
fork the plugin, make it compatible with an API option and then issue a
pull request so others can enjoy benefit of my work.
When you say "how the key is being managed", you mean figuring out what
attribute of the session that the key into the backing store is being
set into? Does this actually take a lot of time as compared to all the
time it takes to figure out how the session machinery stores its data so
you can yank it out later? If so, please describe the wheels you need
to reinvent here and one-off fixes you need to do. Does my composition
example give you any ideas about how to fix it without patching anything?
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
