On Sat, 21 Dec 2002 12:26:04 -0500, Steve Waterbury <waterbug@beeblebrox.gsfc.nasa.gov> wrote:

We are not using sessions yet, but plan to in the near future.

Good... the "near future" will be a good time to start :-)

Currently we are using the twisted xmlrpc for communication to our GUI client (developed using wxPython), but we also plan to have a browser interface (almost certainly using Woven), a SOAP interface, and quite possibly others (e.g., PB and/or CORBA).

Wow! Did Twisted inspire you to use such a diverse assortment of frontends, or was it part of your charter and why you chose it in the first place? :)

Do you plan to make your new Sessions implementation general enough to support all of these?

This is a hard question to answer as asked, so I'll take this opportunity to lay out my vision for how multi-protocol "sessions" are supposed to work. There are two answers: yes, I plan to make Session part of a system general enough to support all of these front-ends. Also: no, I do not plan to make Session general enough to support all these itself :-). If you've been a good disciple of the Twisted Way, you'll have a Service with Perspectives that represent the way that users interact with your system. That's the focal point of the conversations your users will have with your abstractions. Web session management is a mostly-separate system, more of a kludge over the HTTP protocol than a general way of representing stateful interaction. The cool thing about the new web session wrapper (now checked into CVS in twisted.web.woven.guard) is the fact that it can negotiate with the browser to discover whether cookies are turned on, more or less automatically, and provide effectively the same experience whether they are or not. I'm still working on the web part of the cross-protocol part of this system. In twisted.cred, there are 4 real abstractions documented so far: identity, perspective, service, authorizer. There is a 5th though, which has really only been used by PB so far: the notion of a "client object". (That's a terrible name, I know, but it seems to describe its function.) Abstractly, the client object is representative of the "other side" of some connection to the user. In PB, it's usually a RemoteReference that the client sends as part of the authentication sequence, so the service's side of the interface to this object will often be through callRemote. (There are no restrictions on what kind of object it is, though, so your service is welcome to do whatever is appropriate.) In the case of something like IRC, the "client" will simply be an instance wrapping the IRC Protocol instance. For the web, it will be an object stuck to your Session (which has been initialized using the handshake code above). In the PB case, it's an instance of an object on the other side of the Broker, as I said above. Once you've decided what kind of client object you're using, however, the 'attached' method of your perspective will be called with it. When you log out / your broker goes stale / your IRC connection drops / your web session times out, the symmetric "detached" method is called. I hope that this explains what how should be expecting to use the authentication part of the new twisted.web.woven.guard once it's finished, but feel free to ask for clarification. I really can't think of how to express this well :-).

(Given your usual sound architectural principles, I would expect so, but you might have practical reasons to make it more specific, so just thought I'd ask. :^)

-YES-. MY DESIGN-FU IS STRONG RARARA -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |

There's some good news, and some bad news. First the bad news: On Sat, 21 Dec 2002 22:54:06 +0200, Tommi Virtanen <tv@twistedmatrix.com> wrote:

All in all, I suggest reading ldaptor sources, if you have time and can suppress the vomiting reflex -- there are parts that make me sick, too. But in general it's starting to shape up nicely.

I just did so. Ldaptor itself didn't gross me out too much. However, the webui module was... unfortunate :-(. I notice you're using web.widgets (which we have noisily been attempting to deprecate for the last 3 months or so) for the UI. I don't think there's really much of an upgrade path beyond "rewrite most of your web UI logic", especially if you want to take advantage of some of the new features coming online in woven. Now for some good news: Everything you're doing now will continue to work for quite some time into the future, since twisted.web.widgets was the only way to do dynamic content in Twisted for most of its lifetime. Even the server.Session and guard.ResourceGuard classes are being left in place and gradually deprecated in favor of woven.guard.SessionWrapper and woven.guard.PerspectiveWrapper. You should be able to migrate one function at a time very gradually.

Ldaptor uses HTTP sessions for all everything else but read-only operations. A connection to the LDAP server is actually stored into the HTTP session data. One specific requirement is the ability to expire the HTTP session and ask for reauthentication when the LDAP server connection is lost.

The new woven.guard module will feature not only session expiry but authentication expiry without creating a new session. Additionally it will support URL-based sessions if your browser doesn't feel like allowing cookies. It will also feature a more graceful way to log in to multiple perspectives at a time. If your application is amenable to it, you may even be able to perform a simple sort of web-based capability exchange, where you can temporarily give another user a limited permission to act as you in some regards but not others, by exchanging a generated session URL.

PS. Losing POST form input due to missing authentication sucks. If you can find a clean way around that, I would appreciate it.

And of course this will be fixed :-). There are many reasons why I *wanted* to rewrite the sessions stuff, but this is why I *had* to do it. Pretty much everything in the world that I need to be authenticated involves at least 3 form POSTs. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |

On Sat, 21 Dec 2002 12:26:04 -0500, Steve Waterbury <waterbug@beeblebrox.gsfc.nasa.gov> wrote:

We are not using sessions yet, but plan to in the near future.

Good... the "near future" will be a good time to start :-)

Currently we are using the twisted xmlrpc for communication to our GUI client (developed using wxPython), but we also plan to have a browser interface (almost certainly using Woven), a SOAP interface, and quite possibly others (e.g., PB and/or CORBA).

Wow! Did Twisted inspire you to use such a diverse assortment of frontends, or was it part of your charter and why you chose it in the first place? :)

Do you plan to make your new Sessions implementation general enough to support all of these?

This is a hard question to answer as asked, so I'll take this opportunity to lay out my vision for how multi-protocol "sessions" are supposed to work. There are two answers: yes, I plan to make Session part of a system general enough to support all of these front-ends. Also: no, I do not plan to make Session general enough to support all these itself :-). If you've been a good disciple of the Twisted Way, you'll have a Service with Perspectives that represent the way that users interact with your system. That's the focal point of the conversations your users will have with your abstractions. Web session management is a mostly-separate system, more of a kludge over the HTTP protocol than a general way of representing stateful interaction. The cool thing about the new web session wrapper (now checked into CVS in twisted.web.woven.guard) is the fact that it can negotiate with the browser to discover whether cookies are turned on, more or less automatically, and provide effectively the same experience whether they are or not. I'm still working on the web part of the cross-protocol part of this system. In twisted.cred, there are 4 real abstractions documented so far: identity, perspective, service, authorizer. There is a 5th though, which has really only been used by PB so far: the notion of a "client object". (That's a terrible name, I know, but it seems to describe its function.) Abstractly, the client object is representative of the "other side" of some connection to the user. In PB, it's usually a RemoteReference that the client sends as part of the authentication sequence, so the service's side of the interface to this object will often be through callRemote. (There are no restrictions on what kind of object it is, though, so your service is welcome to do whatever is appropriate.) In the case of something like IRC, the "client" will simply be an instance wrapping the IRC Protocol instance. For the web, it will be an object stuck to your Session (which has been initialized using the handshake code above). In the PB case, it's an instance of an object on the other side of the Broker, as I said above. Once you've decided what kind of client object you're using, however, the 'attached' method of your perspective will be called with it. When you log out / your broker goes stale / your IRC connection drops / your web session times out, the symmetric "detached" method is called. I hope that this explains what how should be expecting to use the authentication part of the new twisted.web.woven.guard once it's finished, but feel free to ask for clarification. I really can't think of how to express this well :-).

(Given your usual sound architectural principles, I would expect so, but you might have practical reasons to make it more specific, so just thought I'd ask. :^)

-YES-. MY DESIGN-FU IS STRONG RARARA -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |

There's some good news, and some bad news. First the bad news: On Sat, 21 Dec 2002 22:54:06 +0200, Tommi Virtanen <tv@twistedmatrix.com> wrote:

All in all, I suggest reading ldaptor sources, if you have time and can suppress the vomiting reflex -- there are parts that make me sick, too. But in general it's starting to shape up nicely.

I just did so. Ldaptor itself didn't gross me out too much. However, the webui module was... unfortunate :-(. I notice you're using web.widgets (which we have noisily been attempting to deprecate for the last 3 months or so) for the UI. I don't think there's really much of an upgrade path beyond "rewrite most of your web UI logic", especially if you want to take advantage of some of the new features coming online in woven. Now for some good news: Everything you're doing now will continue to work for quite some time into the future, since twisted.web.widgets was the only way to do dynamic content in Twisted for most of its lifetime. Even the server.Session and guard.ResourceGuard classes are being left in place and gradually deprecated in favor of woven.guard.SessionWrapper and woven.guard.PerspectiveWrapper. You should be able to migrate one function at a time very gradually.

Ldaptor uses HTTP sessions for all everything else but read-only operations. A connection to the LDAP server is actually stored into the HTTP session data. One specific requirement is the ability to expire the HTTP session and ask for reauthentication when the LDAP server connection is lost.

The new woven.guard module will feature not only session expiry but authentication expiry without creating a new session. Additionally it will support URL-based sessions if your browser doesn't feel like allowing cookies. It will also feature a more graceful way to log in to multiple perspectives at a time. If your application is amenable to it, you may even be able to perform a simple sort of web-based capability exchange, where you can temporarily give another user a limited permission to act as you in some regards but not others, by exchanging a generated session URL.

PS. Losing POST form input due to missing authentication sucks. If you can find a clean way around that, I would appreciate it.

And of course this will be fixed :-). There are many reasons why I *wanted* to rewrite the sessions stuff, but this is why I *had* to do it. Pretty much everything in the world that I need to be authenticated involves at least 3 form POSTs. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |