how to modify text in html form from python

[Philippe C. Martin]

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