"Philippe C. Martin" <[EMAIL PROTECTED]> writes:
>> You've got lots of stuff going on here. I count at least five programs
>> and three network connections. How much is working, and which parts
>> are you trying to do in Python?
>
> I am starting from existing applications (cross-platform - and in python
> 99% ) that work even through tcp-ip (sockets).
>
> I am just trying to apply them to a web environement.
>
> So prior to any user interaction with the page, I need some data exchange
> between the plugin and the server (authentication).
I don't know much about plugins. I believe they get started when the
page loads, which gives you a chance to do the authentication when you
want it done.
> So _if_ (I'm a web newbie) the server and the clien(plugin) could exchange
> data through some form field, my prototype would be much further along.
That won't work very well. HTML goes to the client to display. The
server can put data in hidden form elements that code running on the
client side can get to - and change - via the document object model
(DOM). However, the only way to send the changed data back to the
server is to get the client to submit the form. You can automate that,
but the results will be disconcerting to the user: they load a page,
and it reloads multiple times as the plugin exchanges data with the
server.
> Here is a small picture:
> Smart Card <-> driver <-> cgi <-> apache ...... [NET]........ browser <->
> plugin <-> driver <-> Smart Card
The problem with this is that the apache<->browser connection isn't
"a" connection, it's a series of HTTP request/repsonse
pairs. Originally, this implied tearing down and setting up a TCP
connection for every request. Modern software will leave the link open
and reuse it - but modern software also tends to have multiple
connetions open, so it can fetch images and other embedded objects in
parallel.
You can make this work, but doing it like that requires making
multiple HTTP requests via the browser, which will be
disconcerting. I'd recommend taking the browser out of the loop. Have
the plugin talk directly to the server to do the
authentication. That's what the latest web buzzword (AJAX) does:
client-side software makes independent requests of the server (or
*any* server) to get data, and possibly updates the document the
browser is viewing as a result of that.
So here's a scenario: the first cgi script gets info from the smart
card that puts it in a hidden form element and sends the page to the
browser. The plugin - started when the page loads - uses the DOM to
get that data, then makes an *independent* HTTP request to the server,
thus passing whatever it generated from the data in the form field to
a second cgi script. This happens several times, then the plugin
changes the HTML form to put whatever the cgi script generated into
the form, so that when the user finally submits the form, the third
cgi script - the one that handles the submitted form - sees the data
from the second script.
Actually, the exchanges between the plugin and the server don't need
to be HTTP requests. If you've got this working over some other TCP
protocol, there's no reason you can't keep doing it that way.
A word of warning: authentication protocols are fragile; they tend to
stop being resistant to attacks after even relatively minor changes,
so you want to be very carefull about changing the protocol. Web-based
things are very open. You can't really do much to prevent the client
end from doing *whatever they want* with the HTML you send them, or
you generate for them on the fly. This also has serious security
implications. Think carefully about what happens when the user pulls
one of your forms out of the browser history, or bookmarks a
page. Then make sure you get a thorough audit of the resulting
system/protocol done by people who know what they're doing.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
