By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,482 Members | 3,157 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,482 IT Pros & Developers. It's quick & easy.

how to modify text in html form from python

P: n/a
Hi,

I am trying to change the data in a form field from python. The following
code does not crash but has no effect as if "form" is just a copy of the
original html form.

Must I recreate the form order to do that ?

My point is for the client to be able to re-read the modified data.
Thanks,

Philippe
#!/usr/bin/python

import cgi
import os
import sys
import logging
import cgi
sys.stderr = sys.stdout
print "Content-type: text/html\n"
try:
form = cgi.FieldStorage()
#logging.warning (form)

except:
logging.exception("\nEXCEPTION 1")
try:

form['tosrv'].value = "TEST"
except:
logging.exception("\nEXCEPTION 2")
pass

<html>
<body>
<title>Smart Logon</title>
<h1>Smart Logon</h1>
<hr>
<FORM METHOD=POST ACTION="/cgi-bin/scfbweb.py">
<table>
<TR><TD>
<INPUT TYPE=HIDDEN NAME="key" VALUE="process">
TO SERVER:<BR>
<INPUT type=text NAME="tosrv" value="TO" size=60>
<BR>
FROM SERVER<BR>
<INPUT type=text name="fromsrv" value="FROM" size=60>
<P>
<INPUT TYPE="SUBMIT" VALUE="START">

</TD></TR></table>
</FORM>
</body>
</html>
Oct 21 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
PS: If my question is not clear, I am trying to "share" the form between the
client and server.

just as many sites out there allow you to modify existing data:
1) the server pops up a form with your data in it.
2) the client can modify it and submit.

I know this is a _basic_ question, sorry.

Philippe

Philippe C. Martin wrote:
Hi,

I am trying to change the data in a form field from python. The following
code does not crash but has no effect as if "form" is just a copy of the
original html form.

Must I recreate the form order to do that ?

My point is for the client to be able to re-read the modified data.
Thanks,

Philippe
#!/usr/bin/python

import cgi
import os
import sys
import logging
import cgi
sys.stderr = sys.stdout
print "Content-type: text/html\n"
try:
form = cgi.FieldStorage()
#logging.warning (form)

except:
logging.exception("\nEXCEPTION 1")
try:

form['tosrv'].value = "TEST"
except:
logging.exception("\nEXCEPTION 2")
pass

<html>
<body>
<title>Smart Logon</title>
<h1>Smart Logon</h1>
<hr>
<FORM METHOD=POST ACTION="/cgi-bin/scfbweb.py">
<table>
<TR><TD>
<INPUT TYPE=HIDDEN NAME="key" VALUE="process">
TO SERVER:<BR>
<INPUT type=text NAME="tosrv" value="TO" size=60>
<BR>
FROM SERVER<BR>
<INPUT type=text name="fromsrv" value="FROM" size=60>
<P>
<INPUT TYPE="SUBMIT" VALUE="START">

</TD></TR></table>
</FORM>
</body>
</html>


Oct 21 '05 #2

P: n/a
Philippe C. Martin wrote:
PS: If my question is not clear, I am trying to "share" the form between the
client and server.

just as many sites out there allow you to modify existing data:
1) the server pops up a form with your data in it.
2) the client can modify it and submit.

I know this is a _basic_ question, sorry.


When debugging Python cgi scripts, it is helpful to run the scripts from a
command line just to make sure there aren't any compiler errors. Depending on
how the server is set up, you'll get a server error or just a blank page if your
script won't compile. When I run your script directly as I suggest, here's what
I get:

pmcnett@sol:~$ python test.py
File "test.py", line 23
<html>
^
SyntaxError: invalid syntax

D'oh! You needed to surround the html with quotes to make it a string, as in:

print """
<html>
....
</html>
"""

I don't really understand your original problem, but perhaps this will help get
you rolling again.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
Oct 21 '05 #3

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> writes:
PS: If my question is not clear, I am trying to "share" the form between the
client and server.
Yes, your question is not clear. And this statement doesn't clarify
it. That you quoted the "share" shows you are probably aware of this,
if not consciously so.
just as many sites out there allow you to modify existing data:
1) the server pops up a form with your data in it.
2) the client can modify it and submit.
This doesn't really help, either. The server can't "pop up" a form;
only the client can do that. All the server can do is send data to
the client.

The client can't modify data on the server. It can send data to the
server, but that arrives as *new* data. The server can use that to
replace old data, thus modifying that old data.
I know this is a _basic_ question, sorry.
It's not clear it's a basic question, because it's not clear what
you're trying to do.

Try answering these questions:

Where do you expect the HTML to come from?
Where do you expect the data originally in the HTML form to come from?
Where do you expect the data the user inputs into the form to be stored?

<mike

Philippe

Philippe C. Martin wrote:
Hi,

I am trying to change the data in a form field from python. The following
code does not crash but has no effect as if "form" is just a copy of the
original html form.

Must I recreate the form order to do that ?

My point is for the client to be able to re-read the modified data.
Thanks,

Philippe
#!/usr/bin/python

import cgi
import os
import sys
import logging
import cgi
sys.stderr = sys.stdout
print "Content-type: text/html\n"
try:
form = cgi.FieldStorage()
#logging.warning (form)

except:
logging.exception("\nEXCEPTION 1")
try:

form['tosrv'].value = "TEST"
except:
logging.exception("\nEXCEPTION 2")
pass

<html>
<body>
<title>Smart Logon</title>
<h1>Smart Logon</h1>
<hr>
<FORM METHOD=POST ACTION="/cgi-bin/scfbweb.py">
<table>
<TR><TD>
<INPUT TYPE=HIDDEN NAME="key" VALUE="process">
TO SERVER:<BR>
<INPUT type=text NAME="tosrv" value="TO" size=60>
<BR>
FROM SERVER<BR>
<INPUT type=text name="fromsrv" value="FROM" size=60>
<P>
<INPUT TYPE="SUBMIT" VALUE="START">

</TD></TR></table>
</FORM>
</body>
</html>


--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 21 '05 #4

P: n/a
Thanks Paul but I was not clear:

the html page is separate from the python script, it calls the python script
when the button is clicked.

The indentation error must be because of my cut and paste.

PS: My goal is to be able to exchange data between the server and the client
(browser plugin) as I have not yet found an easier way.

Regards,

Philippe


Paul McNett wrote:
Philippe C. Martin wrote:
PS: If my question is not clear, I am trying to "share" the form between
the client and server.

just as many sites out there allow you to modify existing data:
1) the server pops up a form with your data in it.
2) the client can modify it and submit.

I know this is a _basic_ question, sorry.


When debugging Python cgi scripts, it is helpful to run the scripts from a
command line just to make sure there aren't any compiler errors. Depending
on how the server is set up, you'll get a server error or just a blank
page if your script won't compile. When I run your script directly as I
suggest, here's what I get:

pmcnett@sol:~$ python test.py
File "test.py", line 23
<html>
^
SyntaxError: invalid syntax

D'oh! You needed to surround the html with quotes to make it a string, as
in:

print """
<html>
...
</html>
"""

I don't really understand your original problem, but perhaps this will
help get you rolling again.


Oct 21 '05 #5

P: n/a
Mike,

Here is what I am trying to do:

**** WHAT ****
-) a client opens his/her browser and click on some button which triggers my
plugin
-) the plugin starts to communicate with a server on some URL.
-) the communication between the server and the client involves a few
exchanges: data from client to server, then from server to client,.....
-) just for info (I do not think it's relevant to my problem) on each side
(server and client) there is a smart card (that's why I need a plugin) and
the information exchanged comes from/go to the smart cards
-) The smart card on the server side eventually decides whether or not the
smart client on the client side is OK and tells so to the cgi script which
acts accordingly

***** HOW (if there's a better way let me know please) ******
As I have not found any better solution yet, I am trying to do the following
(on the server there is an html file and a cgi file)

-) the plugging opens the correct url which has a form with a "click" button
-) the customer clicks on the button
-) the server "puts" some information in a hidden form field (info from
local smart card)
-) the pluggin fetches the information from the form field and gives it to
its local smart card
........ (this a couple of time)
-) the cgi script gets the final verdict from the server smart card and acts
accordingly.

I hope that is clearer.

Regards,

Philippe

Mike Meyer wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:
PS: If my question is not clear, I am trying to "share" the form between
the client and server.


Yes, your question is not clear. And this statement doesn't clarify
it. That you quoted the "share" shows you are probably aware of this,
if not consciously so.
just as many sites out there allow you to modify existing data:
1) the server pops up a form with your data in it.
2) the client can modify it and submit.


This doesn't really help, either. The server can't "pop up" a form;
only the client can do that. All the server can do is send data to
the client.

The client can't modify data on the server. It can send data to the
server, but that arrives as *new* data. The server can use that to
replace old data, thus modifying that old data.
I know this is a _basic_ question, sorry.


It's not clear it's a basic question, because it's not clear what
you're trying to do.

Try answering these questions:

Where do you expect the HTML to come from?
Where do you expect the data originally in the HTML form to come from?
Where do you expect the data the user inputs into the form to be stored?

<mike

Philippe

Philippe C. Martin wrote:
Hi,

I am trying to change the data in a form field from python. The
following code does not crash but has no effect as if "form" is just a
copy of the original html form.

Must I recreate the form order to do that ?

My point is for the client to be able to re-read the modified data.
Thanks,

Philippe
#!/usr/bin/python

import cgi
import os
import sys
import logging
import cgi
sys.stderr = sys.stdout
print "Content-type: text/html\n"
try:
form = cgi.FieldStorage()
#logging.warning (form)

except:
logging.exception("\nEXCEPTION 1")
try:

form['tosrv'].value = "TEST"
except:
logging.exception("\nEXCEPTION 2")
pass

<html>
<body>
<title>Smart Logon</title>
<h1>Smart Logon</h1>
<hr>
<FORM METHOD=POST ACTION="/cgi-bin/scfbweb.py">
<table>
<TR><TD>
<INPUT TYPE=HIDDEN NAME="key" VALUE="process">
TO SERVER:<BR>
<INPUT type=text NAME="tosrv" value="TO" size=60>
<BR>
FROM SERVER<BR>
<INPUT type=text name="fromsrv" value="FROM" size=60>
<P>
<INPUT TYPE="SUBMIT" VALUE="START">

</TD></TR></table>
</FORM>
</body>
</html>


Oct 21 '05 #6

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> writes:
Mike,

Here is what I am trying to do:

**** WHAT ****
-) a client opens his/her browser and click on some button which triggers my
plugin
-) the plugin starts to communicate with a server on some URL.
-) the communication between the server and the client involves a few
exchanges: data from client to server, then from server to client,.....
-) just for info (I do not think it's relevant to my problem) on each side
(server and client) there is a smart card (that's why I need a plugin) and
the information exchanged comes from/go to the smart cards
-) The smart card on the server side eventually decides whether or not the
smart client on the client side is OK and tells so to the cgi script which
acts accordingly

***** HOW (if there's a better way let me know please) ******
As I have not found any better solution yet, I am trying to do the following
(on the server there is an html file and a cgi file)

-) the plugging opens the correct url which has a form with a "click" button
-) the customer clicks on the button
-) the server "puts" some information in a hidden form field (info from
local smart card)
-) the pluggin fetches the information from the form field and gives it to
its local smart card
....... (this a couple of time)
-) the cgi script gets the final verdict from the server smart card and acts
accordingly.

I hope that is clearer.


Some. To continue clarifying:

The phrase "cgi script" refers to a server-side script that is run in
response to the user clicking something on the client. That's what you
expect it to be, right?

Do you expect the plugin to display a form? Or to ouput a form that
the client will display?

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?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 21 '05 #7

P: n/a
Mike Meyer wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:

Some. To continue clarifying:

The phrase "cgi script" refers to a server-side script that is run in
response to the user clicking something on the client. That's what you
expect it to be, right?
Yes, the cgi script on the server side hooks up to the local (server) smart
card
Do you expect the plugin to display a form? Or to ouput a form that
the client will display? No, I want of all the "html" stuff to be handled by the server

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).

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.
Here is a small picture:
Smart Card <-> driver <-> cgi <-> apache ...... [NET]........ browser <->
plugin <-> driver <-> Smart Card


Regards,

Philippe

<mike


Oct 21 '05 #8

P: n/a
I feel fairly stupid ... but to my defense in the past 17 years of coding,
i've only spent 3 days looking at web stuff:

I now can understand how "writing" to an existing form field from a cgi
script might not work: how would the browser know ?: unless there is a very
sophisticated scheme there (as those used in image transfer), I assume the
complete page would have to be sent back: so might as well
regenerate/rewrite everything.

Yes ?

I so, I'm back to finding a way for a browser plugin and a server based cgi
script to exchange information.

Any idea welcome... I know I don't want to open another socket/port but
stick to http:80
Regards,

Philippe



Mike Meyer wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:
Mike,

Here is what I am trying to do:

**** WHAT ****
-) a client opens his/her browser and click on some button which triggers
my plugin
-) the plugin starts to communicate with a server on some URL.
-) the communication between the server and the client involves a few
exchanges: data from client to server, then from server to client,.....
-) just for info (I do not think it's relevant to my problem) on each
side (server and client) there is a smart card (that's why I need a
plugin) and the information exchanged comes from/go to the smart cards
-) The smart card on the server side eventually decides whether or not
the smart client on the client side is OK and tells so to the cgi script
which acts accordingly

***** HOW (if there's a better way let me know please) ******
As I have not found any better solution yet, I am trying to do the
following (on the server there is an html file and a cgi file)

-) the plugging opens the correct url which has a form with a "click"
button -) the customer clicks on the button
-) the server "puts" some information in a hidden form field (info from
local smart card)
-) the pluggin fetches the information from the form field and gives it
to its local smart card
....... (this a couple of time)
-) the cgi script gets the final verdict from the server smart card and
acts accordingly.

I hope that is clearer.


Some. To continue clarifying:

The phrase "cgi script" refers to a server-side script that is run in
response to the user clicking something on the client. That's what you
expect it to be, right?

Do you expect the plugin to display a form? Or to ouput a form that
the client will display?

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?

<mike


Oct 21 '05 #9

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 21 '05 #10

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> writes:
I feel fairly stupid ... but to my defense in the past 17 years of coding,
i've only spent 3 days looking at web stuff:

I now can understand how "writing" to an existing form field from a cgi
script might not work: how would the browser know ?: unless there is a very
sophisticated scheme there (as those used in image transfer), I assume the
complete page would have to be sent back: so might as well
regenerate/rewrite everything.

Yes ?

I so, I'm back to finding a way for a browser plugin and a server based cgi
script to exchange information.

Any idea welcome... I know I don't want to open another socket/port but
stick to http:80


Then you're out of luck. You can't even depend on their being an open
http connection available to use when the plugin runs. The browser may
well do: Load all data. Close connections. Render page as far as we
can. Launch code objects that we loaded.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 21 '05 #11

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> writes:
***** HOW (if there's a better way let me know please) ******
As I have not found any better solution yet, I am trying to do the following
(on the server there is an html file and a cgi file)


If I understand it, you're trying to use a smart card to authenticate
a web site login. The major browsers already have smart card interfaces
(Windows CAPI for MSIE, or PKCS11 for Netscape/Moz*) so you shouldn't
need a plugin. On the other hand, smart cards are very slow.

The typical approach is as follows (MSIE version). Stop using special
smart card programs and just use a card that implements CAPI with a
from the vendor and that can sign against an X509 certificate. The
CSP will have a special signature that makes it less scary to install
than a browser plugin. You'll have to issue a cert for the smart card
and there's various approaches to that, so I'll skip that part. Set
up a TLS server to require a client cert from the CA that signed the
smart card. The browser should recognize the challenge and select the
right cert. The CSP will have its own interface for the user entering
a PIN along with inserting the card. Once you have the TLS connection
established, set a secure cookie in the client session and then redirect
the browser to another URL that doesn't require the smart card (because
otherwise the card will have to re-authenticate every click, which is
very slow). From then on, use the cookie for authentication (it can
have a timeout or whatever).
Oct 21 '05 #12

P: n/a
Paul,

That won't cut it: The cards I use/code do not have RSA capabilities but
only symmetrical algorithms (AES, 3DES, ....). I use the same type of
authentication you would see between a POS and a Smart Card (ex: B0' in
France)

So I cannot hookup to one of the standards (PKCS11 or CSP).

Thanks anyway.

Regards,

Philippe

Paul Rubin wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:
***** HOW (if there's a better way let me know please) ******
As I have not found any better solution yet, I am trying to do the
following (on the server there is an html file and a cgi file)


If I understand it, you're trying to use a smart card to authenticate
a web site login. The major browsers already have smart card interfaces
(Windows CAPI for MSIE, or PKCS11 for Netscape/Moz*) so you shouldn't
need a plugin. On the other hand, smart cards are very slow.

The typical approach is as follows (MSIE version). Stop using special
smart card programs and just use a card that implements CAPI with a
from the vendor and that can sign against an X509 certificate. The
CSP will have a special signature that makes it less scary to install
than a browser plugin. You'll have to issue a cert for the smart card
and there's various approaches to that, so I'll skip that part. Set
up a TLS server to require a client cert from the CA that signed the
smart card. The browser should recognize the challenge and select the
right cert. The CSP will have its own interface for the user entering
a PIN along with inserting the card. Once you have the TLS connection
established, set a secure cookie in the client session and then redirect
the browser to another URL that doesn't require the smart card (because
otherwise the card will have to re-authenticate every click, which is
very slow). From then on, use the cookie for authentication (it can
have a timeout or whatever).


Oct 21 '05 #13

P: n/a
Mike Meyer wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:
I feel fairly stupid ... but to my defense in the past 17 years of
coding, i've only spent 3 days looking at web stuff:

I now can understand how "writing" to an existing form field from a cgi
script might not work: how would the browser know ?: unless there is a
very sophisticated scheme there (as those used in image transfer), I
assume the complete page would have to be sent back: so might as well
regenerate/rewrite everything.

Yes ?

I so, I'm back to finding a way for a browser plugin and a server based
cgi script to exchange information.

Any idea welcome... I know I don't want to open another socket/port but
stick to http:80


Then you're out of luck. You can't even depend on their being an open
http connection available to use when the plugin runs. The browser may
well do: Load all data. Close connections. Render page as far as we
can. Launch code objects that we loaded.

<mike

But the plugin "opened" the connection: var l_w = window.open(l_url,"");

Philippe

Oct 21 '05 #14

P: n/a
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


Oct 21 '05 #15

P: n/a
"Philippe C. Martin" <pm*****@snakecard.com> writes:
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


I think we don't mean the same thing when we say "plugin". To me, a
plugin is a bit of code that gets executed when the page is rendered
to provide custom content with it's own behavior. Flash is probably
the most popular example. Like I said, I don't know much about
plugins, so they may be usable in other ways.
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 ?


Not if you're using plugin as defined above. Pretty much anything that
happens on the browser end is triggered by things happening in HTML -
which means it has to be displayed. I don't know of any way to
download something to the browser to run without rendering *something*
in the browser window - even if it's only a blank plage.
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


HTTP is a stateless protocol. Every HTTP request goes the same: the
client sends a request saying what object it wants from the
server. The server reads the request, and sends back the response,
which is a collection of HTTP headers and a string of bytes. There's
lots more details invovled, and various things you can do to enhance
the performance of the system, but functionally they all boil down to
that.
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.


If you say so. But certainly not through the browser.
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.


I honestly don't know. HTTP does a strict onetime turnaround - the
client sends, then the server sends, then you're done. There are hooks
in the protocol to allow a connection to be resused, but that's a
different request/response pair, and generally handled by the server,
not the cgi script. After all, the next request from the client may be
for some static file instead of the output of a cgi script.

Having a cgi script start two-way communications on the connection may
well work. But it won't be HTTP, and I wouldn't be at all surprised if
one or more of the components in some web connections - proxies,
caches, firewalls, etc. - choked on it. You're liable to get
apparently random failures depending on all kinds of exotic things.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 22 '05 #16

P: n/a
Mike,

Again, thanks.

By plugin I mean the browsers' extensions: ex:
http://roachfiend.com/archives/2004/...nsions/#more-4.
IE has the same type or resorts also to activeX components.

Right now I know how to program that guy to open a url....

I guess I need to some thinking before I ask more questions.

Regards,

Philippe


Mike Meyer wrote:
"Philippe C. Martin" <pm*****@snakecard.com> writes:
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


I think we don't mean the same thing when we say "plugin". To me, a
plugin is a bit of code that gets executed when the page is rendered
to provide custom content with it's own behavior. Flash is probably
the most popular example. Like I said, I don't know much about
plugins, so they may be usable in other ways.
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 ?


Not if you're using plugin as defined above. Pretty much anything that
happens on the browser end is triggered by things happening in HTML -
which means it has to be displayed. I don't know of any way to
download something to the browser to run without rendering *something*
in the browser window - even if it's only a blank plage.
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


HTTP is a stateless protocol. Every HTTP request goes the same: the
client sends a request saying what object it wants from the
server. The server reads the request, and sends back the response,
which is a collection of HTTP headers and a string of bytes. There's
lots more details invovled, and various things you can do to enhance
the performance of the system, but functionally they all boil down to
that.
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.


If you say so. But certainly not through the browser.
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.


I honestly don't know. HTTP does a strict onetime turnaround - the
client sends, then the server sends, then you're done. There are hooks
in the protocol to allow a connection to be resused, but that's a
different request/response pair, and generally handled by the server,
not the cgi script. After all, the next request from the client may be
for some static file instead of the output of a cgi script.

Having a cgi script start two-way communications on the connection may
well work. But it won't be HTTP, and I wouldn't be at all surprised if
one or more of the components in some web connections - proxies,
caches, firewalls, etc. - choked on it. You're liable to get
apparently random failures depending on all kinds of exotic things.

<mike


Oct 22 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.