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> 16 2838
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>
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
"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.
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.
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>
"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.
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
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
"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.
"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.
"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).
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).
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
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
"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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chris McKeever |
last post by:
I am trying to modify the Mailman Python code to stop mapping
MIME-types and use the extension of the attachment instead. I am
pretty much clueless as to what I need to do here, but I think I have...
|
by: Xah Lee |
last post by:
20050207 text pattern matching
# -*- coding: utf-8 -*-
# Python
# suppose you want to replace all strings of the form
# <img src="some.gif" width="30" height="20">
# to
# <img...
|
by: Veeven |
last post by:
Hi,
Suppose I have an XML file like this on the web, say,
http://www.example.com/list.xml
<?xml version='1.0'?>
<list>
<item id='itm01'>
<name>Item 1</name>
<desc>This is item 1</desc>
|
by: python |
last post by:
hello and thanks for reading this,
i have been a dos/windows user using some form of the basic language for 30 years now.
i own and run a small programming company and there is one feature that...
|
by: leila |
last post by:
I am developing an ASP.Net application for a client and they need to
modify the page layout from within a form. like the way you edit a
blog template in Blogger. what is the best approach to do...
|
by: tlyczko |
last post by:
Hello Rob B posted this wonderful code in another thread,
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/c84d8538025980dd/6ead9d5e61be85f0#6ead9d5e61be85f0
I could not...
|
by: Martin Mosbæk Christiansen |
last post by:
Hi
I have been searching this group but I haven't found anything I can
use...
Is it possible to remote modify an already open window form from a
local HTML file?
Example (simplified):
1....
|
by: alejandro.valdez |
last post by:
Hello, I'm trying to make a python script that take an email in (raw)
text format, and add a footer to the text (or html) body of the email.
I'm aware of the email and email.mime modules, but I...
|
by: creative1 |
last post by:
I get following error on page :
Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\desiorb\411.php:9) in C:\xampp\htdocs\desiorb\411.php on line 21
when...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |