Re: [Auth]Scenario

[Gordon Hanson]

7/11/01 10:16:28 PM, Ron Burk <address@hidden> wrote:

>If it's possible to do it without JavaScript, that would be great.
>Otherwise, you have to document that it won't work with browsers
>where JavaScript is disabled. In thinking about web sites, I try to
>shoot for the least common denominator when possible: no Java,
>no JavaScript, no cookies, and the client IP address can change from
>one HTTP request to another.
>
>I have never written a plug-in, so if someone else has, maybe
>they could summarize what the options are for communication
>between a plug-in and a web site. Here's my very limited understanding
>(hopefully someone will correct the incorrect parts). I guess I should
>first say that I'm thinking of a Netscape-style plug-in that would
>be largely code-compatible with both IE and Netscape -- maybe other
>people are envisioning writing a lot of independent code for
>each individual browser, not necessarily using the standard Netscape
>plug-in API at all.
>
I agree wholeheartedly here.  I will need to research the netscape plugin API 
(which is supported under Netscape, 
mozilla, IE and opera).


>AFAIK, a plug-in is associated with a MIME type, and it only
>gets a chance to "get control" when the browser encounters
>a page containing an <embed> tag that refers to that MIME type,
>or when a page itself comes back declared as being of that MIME type.
>AFAIK, the browser does not let the server know which plug-ins
>are installed (or at least, I just did a dump of an IE 5.01 request,
>and I see that it just says "Accept: */*", which doesn't seem to
>give me a clue about what it really accepts :-).
>Once it gets control, the plug-in can have its own window,
>can make "behind the scenes" requests (POST/GET) to the server and
>read back responses. Are there other details about the
>Netscape plug-in API that are relevant to this problem?
>
I think (in my limited and aging very quickly) experience that what you have 
said is it in a nutshell. for the initial quick 
and dirty implementation we could use a mime type like authorization/x-dotGNU 
in order to get control and log in for the 
user.  The file that we would get from the embed tag should have all of the 
info that we need to successfully login/setup 
a password.

I havent thought much about what would be necessary server side though..  in 
the simplest case we could use 
POST/GET to get in an the target would be the main window. are there cases 
where we would need a server side 
process?
 
>I'm really exceeding my actual knowledge now, but I have
>this vague memory that my server can transmit a multi-part
>MIME in response to a GET. If so, I wonder what the standard
>browsers would do if I sent a two-part, the first being a MIME
>type that they don't understand (dotgnu MIME type) and the
>second being my fallback text/HTML for people who aren't using
>dotgnu. If they would just ignore the first part when it's a MIME
>type they don't know, that might be an easy way for servers to
>transparently degrade to the dotgnu case. Come to think of it,
>it's something I might enjoy, but probably not that easy for people
>who don't like to whack on Apache, and definitely a pain for
>some non-Apache servers. Probably a bad idea (but included
>here so I can remember why it's a bad idea :-).
>
>Maybe <noembed> would do the trick.
>
>Random thought: I wonder if IE supports the "pluginspage" attribute
>of the <embed> tag.
>

Just checked.  No, unfortunatly it does not (at least up to version 4)

>>1. how can we tell that a logon button has been pressed so we can kick off 
>>the lookup-site/send-password function?
>
>If pressing the logon button takes you to a web page that
>refers to the plug-in's MIME type, then the plug-in should
>get the chance to do its thing.
>
>>2. how can we tell what information is being asked for? I can see how this 
>>would work by embedding either an object
>>tag, or a set of meta tags in the page, and then using the document object 
>>model to retrieve that info.
>
>Seems like, for example, the web server could supply a page
>that contains an <embed> tag whose src attribute refers to
>a something.dotgnu file back on the server. That file can have
>the information request in any form you care for; XML is always
>buzz-word worthy, of course :-). The plug-in would be loaded,
>get a chance to read the server's request (possibly in the
>form of XML), and have a designated space on the page
>to display its UI.
>
>>4. Are we going to use HTTP as the transport protocol ? Are we going to 
>>use XML-RPC, SOAP or IIOP as the
>>communication protocol? (My vote goes for SOAP as it is being ratified by 
>>the w3c)
>
>My vote would be for focusing on making it dead easy for as many
>web site designers as possible. If you can do that with SOAP, then
>great. I'm not sure how that fits with using a standard plug-in.
>Despite the fact that the browser is technically the client, the interaction
>we're interested in is really a conversation driven by the web server,
>I'm thinking. Maybe it's possible to view it either way, though.
>
>If the system were implemented with a Netscape-style plug-in,
>which the web site could communicate with merely by placing
><embed> tags in their HTML (which in turn might cause the
>plug-in to reply via whatever kind of POST or GET the web server
>cares to specify), that might be the simplest form of communication.
>You could use <meta> tags to supply info, but for some reason
>it feels cleaner to me (with my webmaster hat on) to be able to
>place the information request in a separate URL with its own
>file format that gets fetched transparently (e.g., via an <embed>
>reference or somesuch).
>



Oops, sorry I skipped ahead to when this would be implemented in the dotGNU 
framework.
I will try to stay at the quick and dirty first instance level from now on.

thats all I can think of for now.


Gord Hanson