[Web-SIG] Possible specs

[Ian Bicking]

Ben Bangert wrote:
> On Nov 10, 2006, at 10:40 AM, Ian Bicking wrote:
> 
>>      * Ben Bangert suggested a simple session standard, focused solely
>> on the session ID (persistence handled elsewhere). This is fairly  
>> modest
>> but still useful.
> 
> I'll have to find that and take a look as I no longer recall what I  
> was talking about. :)

It's in the web-sig archives somewhere, I think.  It was quite a while ago.

>>      * Debugging mode is something that can be used in all sorts of
>> places; to increase verbosity, annotate output pages, displaying  
>> errors
>> in the browser, etc. Having a single key for turning on debugging mode
>> would allow its consumption in lots of places. Not as strict as
>> authenticating.
> 
> I'd really like this. In addition to having a key that indicates the  
> app is in debug mode, there should probably be one to indicate its in  
> an automated testing mode as well for unit/function tests. The  
> testing one should also provide a key where object ref's can be put  
> for a WSGI unit testing harnass, like  how paste.fixture's TestApp runs.

Yes, I thought about that too.  It can be a good to use as a guard 
against things like sending email.

I don't know if the testing variables necessarily need standardization, 
but I suppose they could have it.  There's no consumers right now 
besides paste.fixture.TestApp.  There are other frameworks that could 
consume those variables, but none of them are very closely integrated 
with WSGI (yet?).  I don't those other frameworks have any way of 
dealing with that kind of information.

>>      * Request object wrapping the environment.
> 
> I'd imagine this would be a base interface?

I'll expand on that in a separate message, as I have a fairly minimal 
spec in mind.

>>      * Configuration takes fairly common forms, usually a dict of some
>> sort. It could be put somewhere standard.
> 
> Yep, should be a pretty minimal spec as well.

It's a little more vague when you have more structured configuration, 
e.g., in Paste Deploy situations you have the global and local 
configuration.  OTOH, the common interface can be a flat dictionary, 
with optional attributes for further optional structure.

>>      * More user information than just REMOTE_USER; like  
>> wsgiorg.user_info?
> 
> I think a base spec for user information could be modeled on the user  
> data information thats in the OpenID 2.0 spec. The same user keys/ 
> values are in the LID spec as well, modeling our environ dict for the  
> wsgiorg.user_info on those spec's would make using them easy, and  
> they account for all the common fields in most every auth system I've  
> encountered.

Where in the spec are those values?

I was mostly thinking it would be a dictionary similar to the WSGI 
environment, and the contents would be fairly vague.  Maybe it would 
have values like user_info['openid.homepage'], all of which would of 
course be optional.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org