FAQ
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`>
<BR>
FROM SERVER<BR>
<INPUT type=text name="fromsrv" value="FROM" size`>
<P>
<INPUT TYPE="SUBMIT" VALUE="START">

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

Search Discussions

  • Philippe C. Martin at Oct 21, 2005 at 7:18 pm
    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`>
    <BR>
    FROM SERVER<BR>
    <INPUT type=text name="fromsrv" value="FROM" size`>
    <P>
    <INPUT TYPE="SUBMIT" VALUE="START">

    </TD></TR></table>
    </FORM>
    </body>
    </html>
  • Paul McNett at Oct 21, 2005 at 7:30 pm

    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 at 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 Meyer at Oct 21, 2005 at 7:34 pm

    "Philippe C. Martin" <pmartin at 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`>
    <BR>
    FROM SERVER<BR>
    <INPUT type=text name="fromsrv" value="FROM" size`>
    <P>
    <INPUT TYPE="SUBMIT" VALUE="START">

    </TD></TR></table>
    </FORM>
    </body>
    </html>
    --
    Mike Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Philippe C. Martin at Oct 21, 2005 at 8:07 pm
    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" <pmartin at 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`>
    <BR>
    FROM SERVER<BR>
    <INPUT type=text name="fromsrv" value="FROM" size`>
    <P>
    <INPUT TYPE="SUBMIT" VALUE="START">

    </TD></TR></table>
    </FORM>
    </body>
    </html>
  • Mike Meyer at Oct 21, 2005 at 8:43 pm

    "Philippe C. Martin" <pmartin at 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 <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Philippe C. Martin at Oct 21, 2005 at 9:00 pm

    Mike Meyer wrote:

    "Philippe C. Martin" <pmartin at 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
  • Mike Meyer at Oct 21, 2005 at 11:00 pm

    "Philippe C. Martin" <pmartin at 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 <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Philippe C. Martin at Oct 21, 2005 at 11:49 pm

    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
  • Mike Meyer at Oct 22, 2005 at 12:28 am

    "Philippe C. Martin" <pmartin at 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 <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Philippe C. Martin at Oct 22, 2005 at 1:06 am
    Mike,

    Again, thanks.

    By plugin I mean the browsers' extensions: ex:
    http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/#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" <pmartin at 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
  • Philippe C. Martin at Oct 21, 2005 at 10:52 pm
    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" <pmartin at 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 at Oct 21, 2005 at 11:16 pm

    "Philippe C. Martin" <pmartin at 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 <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.


    From http Sat Oct 22 01:23:49 2005
    From: http (Paul Rubin)
    Date: 21 Oct 2005 16:23:49 -0700
    Subject: how to modify text in html form from python
    References: <0Ra6f.5050$q%.616@newssvr12.news.prodigy.com>
    <kab6f.5052$q%.1841@newssvr12.news.prodigy.com>
    <86d5lyu0j8.fsf@bhuda.mired.org>
    <%Tb6f.5062$q%.3600@newssvr12.news.prodigy.com>
    Message-ID: <7xbr1ijvy2.fsf@ruckus.brouhaha.com>

    "Philippe C. Martin" <pmartin at 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).
  • Philippe C. Martin at Oct 21, 2005 at 11:39 pm

    Mike Meyer wrote:

    "Philippe C. Martin" <pmartin at 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
  • Philippe C. Martin at Oct 21, 2005 at 11:30 pm
    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" <pmartin at 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).
  • Philippe C. Martin at Oct 21, 2005 at 7:42 pm
    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 at 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedOct 21, '05 at 6:55p
activeOct 22, '05 at 1:06a
posts16
users3
websitepython.org

People

Translate

site design / logo © 2022 Grokbase