Mike Meyer wrote: > > 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.
Well not in this case actually: the user triggers the plugin which in turn open the url, so the connection is "owned" by the plugin > > 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 again, I'm not dying for any page data to be visible: cannot the cgi script and the plugin do their business before that ? > > 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. > I'm lost here, better do some more reading > 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. > Here I think it's OK as the plugin can "talk" to server prior to the browser showing anything. > 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. > Maybe that's my clue: can a cgi script, once triggered by a (let's say) POST request, use back and forth file transfer with the client ? through the _existing_ connection. > 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. > Even if the data when seen, there would not be any security breach as the cards have the keys + algo to understand the data. I realy just need of few tens of bytes to go back and forth (I'm frustrated ;-) Thanks Philippe > <mike -- http://mail.python.org/mailman/listinfo/python-list