Webmaster forum - IE form post oddness

Author

IE form post oddness

jackfoust@gmail.com

2006-09-15, 6:58 pm

I'm trying to POST from a form a simple username and password onto
another website. Firefox and Opera post the data and results are
returned successfully. The site returns "missing user id and password"
when using the same form in Internet Explorer. This form works fine as
a GET, but I want to avoid this route. The site I'm posting to is
fairly closed and I'm not sure if I can get at the perl/c/whatever they
are using to check out the source. Anyone have a clue as to why IE is
misbehaving or the other browsers are breaking standards and actually
working?

<form name="accessform" method="post"
action="http://site/uhtbin/cgisirsi/0/0/30">
<input type="hidden" value="user" name="user_id" />
<input type="hidden" value="password" name="password" />
<p><input type="submit" value="Submit"></p>
</form>

TIA.

Scott Bryce

2006-09-15, 6:58 pm

jackfoust@XXXXXXXXXX wrote:

> I'm trying to POST from a form a simple username and password onto
> another website. Firefox and Opera post the data and results are
> returned successfully. The site returns "missing user id and password"
> when using the same form in Internet Explorer. This form works fine as
> a GET, but I want to avoid this route.

What type of file are you expecting to get in return? IE has a "feature"
(at least older versions did) that may require you to use GET. This
"feature" crops up when the server is generating a file type other than
an HTML or plain text file, and needs the form data to create the file.

I won't comment on the security issue of putting a password in a hidden
field. I'll assume you already know that, or that you have a good reason
to do that.

jfoust

2006-09-15, 6:58 pm

Scott Bryce wrote:
> What type of file are you expecting to get in return? IE has a "feature"
> (at least older versions did) that may require you to use GET. This
> "feature" crops up when the server is generating a file type other than
> an HTML or plain text file, and needs the form data to create the file.
>
> I won't comment on the security issue of putting a password in a hidden
> field. I'll assume you already know that, or that you have a good reason
> to do that.

It is outputting html. I replicated the form that is used on the web
site that is returning the data and it functions fine in IE. It is
only when I move the form to another webserver and have it try to get
results that I run into problems with just IE.

I'm not too concerned with the user going to view source and seeing the
hidden inputs, they are only seeing their actual id and pin, not
somethign system wide. I just want to avoid using GET so that the user
id and password doesn't end up in the cache. A lot of the traffic for
this web site is from shared computers.

Jukka K. Korpela

2006-09-15, 6:58 pm

jackfoust@XXXXXXXXXX <jackfoust@XXXXXXXXXX> scripsit:

> <form name="accessform" method="post"
> action="http://site/uhtbin/cgisirsi/0/0/30">

It's surprising that you claim that the form works on some browsers, given
the fact that the URL in the action attribute isn't even syntactically
correct, due to the malformed server part.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

jfoust

2006-09-15, 6:58 pm

Jukka K. Korpela wrote:
> jackfoust@XXXXXXXXXX <jackfoust@XXXXXXXXXX> scripsit:
>
>
> It's surprising that you claim that the form works on some browsers, given
> the fact that the URL in the action attribute isn't even syntactically
> correct, due to the malformed server part.
>
> --
> Jukka K. Korpela ("Yucca")
> http://www.cs.tut.fi/~jkorpela/

I just shortened the fairly long server address to site, the
/uhtbin/cgisirsi/0/0/30 directory is correct though. There is no file
extension for whatever scripts the server is processing.

Scott Bryce

2006-09-15, 6:59 pm

I don't know if this has anything to do with your problem, but I'll
describe IE's "feature" just in case this helps.

In the early days of the internet, not all servers sent the correct file
type headers for all file types. Of course, the correct solution to the
problem is to fix the servers. That has since happened. But in the mean
time, Microsoft added a Band-Aid to IE. When IE requests a file from the
server, it asks for only a portion of the file. When it gets this
portion, IE examines the content to determine what type of file it is.
IE may decide that the file type is different than the type specified in
the headers.

But here is where the "feature" comes in. IE will then make a second
request to the server for the entire file. If you are sending POST data
to the server, the POST data is not sent with this second request. GET
data is sent, since it is part of the URL. When you think about it, you
wouldn't want POST data sent a second time, since POST is supposed to be
used when the POSTed data will change the server state. Sending it a
second time could mess up data on the server. It would be sorta like
everybody clicking your submit button twice.

So if the content that is sent to the browser is determined by the data
sent to the server, you can't use POST. By the time IE sends a real
request for the content to the server, the POST data has been lost.

I know this was true for IE versions up to 5.x. I don't know if current
versions of IE still do this.

There may be exceptions to this, but I don't remember enough details to
know for sure.

Almost 3 years ago I was bit by this feature. My site generates PDF
files based on data sent to the server. I do most of my testing using
Netscape Navigator. When the site went live, I was unaware the site did
not work for IE users, until I started getting emails from them. It took
a full day to research the problem. I finally figured out what was
happening after finding a related article in the knowledge base at
msdn.com, (I can't find that article now) and noticing that my server
logs showed two requests to the server every time the submit button was
clicked by someone using IE. The solution was to change all my POSTs to
GETs.

jfoust

2006-09-15, 6:59 pm

I just can't seem to figure out why it functions correctly when using
the form on the server of the target website, but not when I replicate
the form and put it on another webserver.

Original form is at
http://sirsi.altoonalibrary.org:808...i/0/0/29/48/X/1
-Using test as user id and test as pin; IE, Firefox and Opera all
return access denied, which they should.

Test form is at
http://www.altoonalibrary.org/sandb...ost_oddness.htm
-Firefox and Opera return access denied.
-IE returns missing user id or alt id.

Scott Bryce

2006-09-24, 6:57 pm

jfoust wrote:

> I just can't seem to figure out why it functions correctly when using
> the form on the server of the target website, but not when I
> replicate the form and put it on another webserver.

Which makes me doubt that the problem you are having is the same as the
problem I was having. But, since it was so difficult for me to hunt
down, I posted it anyway, just in case.

Scott Bryce

2006-09-24, 6:57 pm

jfoust wrote:
> I just can't seem to figure out why it functions correctly when using
> the form on the server of the target website, but not when I replicate
> the form and put it on another webserver.

Because the sirsi.altoonalibrary.org site is including session
information in the URL. You cannot duplicate that on your site. If I
create a dummy form, and paste in the session information from a recent
session, I can get this to work in IE whether I use POST or GET. If the
session is not there, I get a session timed out error.

I suspect what you need to do is use a server side script that will call
the sirsi.altoonalibrary.org site, fill in the form, then post it to the
sirsi.altoonalibrary.org server. That way session information can be
maintained.

Scott Bryce

2006-09-24, 6:57 pm

Scott Bryce wrote:

> I suspect what you need to do is use a server side script that will
> call the sirsi.altoonalibrary.org site, fill in the form, then post
> it to the sirsi.altoonalibrary.org server. That way session
> information can be maintained.

#!/usr/bin/perl
use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);
use WWW::Mechanize;

my $mech = WWW::Mechanize->new();
$mech->get('http://sirsi.altoonalibrary.org:8080/uhtbin/cgisirsi/0/0/29/48/X/1');

die 'Unable to fetch page.' if ! $mech->success();

$mech->submit_form(
form_number => 2,
fields => {
user_id => 'test',
password => 'test'
}
);

die 'Unable to post form.' if ! $mech->success();

# Guessing on the charset.
print "Content-Type: text/html; charset=ISO-8859-1\n\n";

my $base_tag = q(<base href=') . $mech->base() . q('> );
my $page_content = $mech->content();
$page_content =~ s/<\/title>/<\/title>\n$base_tag\n/i;
print $page_content;

jfoust

2006-09-24, 6:58 pm

> Scott Bryce wrote:
>
> I suspect what you need to do is use a server side script that will
> call the sirsi.altoonalibrary.org site, fill in the form, then post
> it to the sirsi.altoonalibrary.org server. That way session
> information can be maintained.

I installed WWW-Mechanize and tried that script. It is coming back
with an unable to fetch page error.

Scott Bryce

2006-09-24, 6:58 pm

jfoust wrote:

> I installed WWW-Mechanize and tried that script. It is coming back
> with an unable to fetch page error.

It works for me.

jfoust

2006-09-24, 6:58 pm

Scott Bryce wrote:
> It works for me.

That is intreresting. I copy/pasted the entire script into a .pl file
in a directory on my IIS server that can run scripts/executables. I
never really do much with perl, I hope I'm not looking over something
trivial.

Scott Bryce

2006-09-24, 6:58 pm

jfoust wrote:

> That is intreresting. I copy/pasted the entire script into a .pl file
> in a directory on my IIS server that can run scripts/executables. I
> never really do much with perl, I hope I'm not looking over something
> trivial.

Very interesting. I can run it from my local machine (Win98SE) or my web
host (Linux/Apache).

jfoust

2006-09-24, 6:58 pm

Scott Bryce wrote:
> Very interesting. I can run it from my local machine (Win98SE) or my web
> host (Linux/Apache).

Tried it on a copy of IIS I have on my desktop and it seems to be
working fine. Maybe it has something to do with URLScan on my
production server. Anyways, thanks a million. I will have a lot of
happy Library patrons when I deploy this.

Jerry Stuckle

2006-09-24, 6:59 pm

Scott Bryce wrote:
> jfoust wrote:
>
>
>
> Very interesting. I can run it from my local machine (Win98SE) or my web
> host (Linux/Apache).

Did you get the file permissions set properly? The IUSR_xxxx account
must have read access to it and execute permission for PERL (and IIS
must be set up to properly parse .pl files as PERL scripts).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

jfoust

2006-09-24, 6:59 pm

Jerry Stuckle wrote:
> Did you get the file permissions set properly? The IUSR_xxxx account
> must have read access to it and execute permission for PERL (and IIS
> must be set up to properly parse .pl files as PERL scripts).

Sadly, it actually turned out to be a dns problem. Didn't have a local
entry for the server but a quick addition to the hosts file cleared
everything up.