On Tue, Feb 9, 2010 at 12:19 PM, Haron Media <[email protected]> wrote: > Take for instance Joe Gregorio's example of a RESTifying the Day Trader > benchmark app. In there he deals with tickets to ensure a an order has > been submitted only once. That obtaining the ticket (or permission to > post it once if you will) is not unlike tokenizing forms.
I was thinking of that example too. But if it's a one-time token, why can't it be put in the form itself? Why does it have to be in a session variable or cookie? The server would just need a cache of which tokens have been distributed and their expiration times (and perhaps other stuff like the client IP and expected submission URL). > Speaking of sessions though, what is the status on the rewrite mentioned > in the docs that should optimize session handling that is not quite > optimally compatible with Beaker caching containers? I don't know about that. It must be one of Ben's projects. >> If you want to prepare a patch for WebHelpers, it will be considered. >> > > Unless someone beats me to it, I most certainly will (look into it). > Currently I am finishing a rather big PHP app for a client You can open a WebHelpers ticket with an outline of a solution. Then somebody might see it and implement it, and it'll be sitting there on the todo list. > and this will > be the last that PHP will ever see of me, then I'm jumping full time > into Python and Pylons. And as I mentioned when I first subscribed, I > have a set of components and practices that I'd like to port to Pylons, > and I believe some of them could be used to better the framework. WebHelpers would be interested in anything that's (1) framework-neutral, (2) without dependencies, and (3) useful to a wide variety of applications. A limited number of Pylons-specific helpers can be accepted for webhelpers.pylonslib. Things that are too useful to ignore, too difficult to make framework-neutral, but not quite core enough or unchanging enough to go into Pylons itself. But framework-neutral helpers are the first choice. >> One issue with cookie-only tokens is they'll still depend on >> Pylons/WebOb, because there's no framework-neutral way to access >> cookies or the HTTP headers. (The helpers aren't in the WSGI call >> chain, so they don't have access to the environ except by that trick >> in url_for which I'm trying to eradicate.) So it would still have to >> go under webhelpers.pylonslib, unless perhaps it had callback args in >> the constructor to get and set a cookie. If you can think of a >> framework-neutral way to do it, that would be most welcome > > I will have to dig deeper in order to answer that, but I understand the > concern. Unlike with sessions (beaker) -- which is in the wsgi chain -- > there is nothing to import in the secure form modules in order to have > access to cookies, correct? OTOH, that means several options: a) make > environ globally available (thread-local?), b) make cookie management a > module/object in itself (like beaker), c) make only subsets of environ > responsible for request and response headers globally available like > (a), or d) forget it, too complicated, if you're using secure forms > you're most likely using sessions to begin with. I previously tried to make a framework-neutral layer for accessing the environ, but it was so much work for so little benefit that I gave up. Instead, I'm just putting Pylons helpers into pylonslib, and reminding other framework developers that they can be ported to other APIs pretty easily. The problem is that an autonomous function has no access to the WSGI data except via its arguments. A middleware could put some kind of multipurpose helper object in the environ, but then you'd be dealing with methods of some huge helper object, not autonomous functions. (Routes does this now: the middleware creates a URLGenerator for the current request and puts it in the environ, and Pylons puts it on ``pylons.url``. But it would be silly to stuff all of WebHelpers into the environ this way.) You can get around this with a threadlocal singleton that contains the environ and the functions can access, but singletons are what I'm trying to stay away from. -- Mike Orr <[email protected]> -- 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.
