dotgnu-auth
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]I think I have it... (browser auth interaction: simple and clean)

From: John
Subject: [Auth]I think I have it... (browser auth interaction: simple and clean)
Date: Thu, 11 Jul 2002 10:37:49 -0400
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
In the last meeting we were concerned about the easiest way for designers to link auth services to both a browser or a webservice. Now for a service this would logically be an XMLRPC or SOAP request that can be recognized by the connecting service and spawned to the DotGNU auth component. Web pages however pose a special problem because: 
1) the interactor is human being using a client, not a client program
2) the interactor makes a decision to authorize or not authorize and may do so at any time during the transaction 3) the webservice is abrogated from accessing profile information until the user authorizes 4) the webpage accessible services are largely already written in HTML and though new services myay surface in other markups, HTML will remain popular for quite sometime. We need to easily link into the existing infrastructure. 
I've been largely opposed to plugins in the past, because, quite frankly 
I couldn't make them work in either the FrePort or MACS context and 
certainly not in a unified context. I've had new insight and I think 
plug-ins, which have been suggested many times in the past, would be 
acceptable, so long as they do not render anything within the current 
page context. Consider the following methodology:

The HTML page will contain in the <head>

<link type="application/x-gnuprofile" 
href="https://the.service.uri.com/link/to/requested/info.gpro";>

All browsers allow us to add media types as plugin, or in the case of 
IE: Active-X. The x-gnuprofile file would contain the necessary 
definition for authorization with the page in question. The browser 
would by following the basic rules of <link> and would download 
the x-gnuprofile file and then pass this data to the plugin? The file 
would contain a static version of the very same commands used in the 
XMLRPC or SOAP call used by a peer to peer webservice. If the user has 
not logged into their profile; the plug-in pops a window and asks 
"[Site] requests you to authorize" with appropriate gadgets to 
accomplish that task. If the user is already logged in the user will be 
asked whether they wish to authorize the transmission of all or part of 
their profile (with confirmation on sensitive transmissions) to the 
service. The user can also be given an opportunity to switch their role 
at this point; roles save users from having multiple accounts and I 
strongly emphasize them in FrePort.  The best of all from our standpoint 
has to be that there is no massive need for support from the web 
developer beyond writing his gpro, which could be a wizard. Greatest 
plus for the web designer: no "login gnu" button need be allocated on 
the web page. They can keep their existing layout, look and feel.

If you think about the proposal, we meet all the requirements of the 
above scenario.

Of course, all the above is contingent on politics as well as 
technology. Will we be required to register the MIME type and extension 
with the appropriate authority, or submit for approval our novel use of 
<link> to the W3C? Will we be required to interact with some search 
registry of plugins and would the powers-that-be try to block our 
access? I can think of other political questions not the least of which 
would be to recruit an ActiveX programmer, but the main question for now 
would be "Does this solve the browser problem?"

John Le'Brecage
















reply via email to








[Prev in Thread]
Current Thread
[Next in Thread]