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

auto POST-ing login data via "javascript:document.form.submit()" link

P: n/a
Hello.

Can anybody solve this problem?

I am using a server-side language (PERL) to *try* to POST data to a
HTTPS login script that doesn't have a standard "submit" button. The
form appears to use javascript to submit the document via the browser's
DOM.

<form action='loginScript.cgi' method="post" name="loginForm">
<input name="userid" />
<input name="password" />
<a href="javascript:document.loginForm.submit()" >
<img src="someImage.gif" >
</a>
</form>

I have verified this by
1) disabling javascript in my a browser and replicating the error of
being unable to submit ... and ...
2) creating my own simple form (roughly the same as the above code)
on my own site to submit the data (to the site of interest) without
problem!

Any ideas on how to use a server side language (PERL preferably) to
submit via this javascript dependent form?

the only think I can think of is to have my server-side language (PERL)
to create and run a
temporary javascript enabled form/webpage and capture the results...
but this would be highly inelegant..

Thanks in advance,

Dave

Jan 3 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
wrote on 03 jan 2006 in comp.lang.javascript:
<a href="javascript:document.loginForm.submit()" >
<img src="someImage.gif" >


Why not use:

<input type='image' src='someImage.gif'>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jan 3 '06 #2

P: n/a
ds******@gmail.com wrote:
<form action='loginScript.cgi' method="post" name="loginForm">
<input name="userid" /> ^[1] <input name="password" /> ^[1] <a href="javascript:document.loginForm.submit()" > `----.,---'`-------.,-------'`---.,--' ^
[2] [3] [4] [5] <img src="someImage.gif" > ^[6] </a>
</form>
[1] IE does not support XHTML, so there is no use in serving it to it.
If it was HTML, it was equivalent to <input ...>&gt; which is just
as bad.

And should not the password `input' element be of type="password"?

[2] The pseudo-protocol `javascript:' does not belong into `href'
attribute values, at least not without a graceful-degrading alternative.
Here, users without enabled client-side script support will not be able
to submit the form. A simple

<input type="image" src="someImage.gif" alt="whatever">

would have sufficed for all UAs newer than Netscape 4.x (1998).

[3] Form/HTMLFormElement objects should be referred to using the `forms'
collection of HTMLDocument objects: document.forms['loginForm'].

[4] Methods should be feature-tested on run-time before they are called:
<URL:http://pointedears.de/scripts/test/whatami#inference>

[5] The HTML 4.01 Specification recommends against whitespace
after the `a' element's start tag and before its end tag:
<URL:http://www.w3.org/TR/html4/struct/text.html#h-9.1>,
"In order to avoid problems with SGML line break rules and
inconsistencies among extant implementations [...]"

[6] The `alt' attribute is missing for this to be Valid HTML.
<URL:http://validator.w3.org/>
[...]
Any ideas on how to use a server side language (PERL preferably) to
submit via this javascript dependent form?
Yes, ask in a Perl newsgroup (comp.lang.perl.*). This does not have
anything to do with J(ava)Script/ECMAScript because what is done there is
nothing but emulating an unnamed submit button; incompetently, if I may
add.
the only think I can think of is to have my server-side language (PERL)
to create and run a temporary javascript enabled form/webpage and capture
the results... but this would be highly inelegant..


Yes, it would, and users would wonder what would happen. However, just for
the sake of completeness, for my RFC Search bookmarklet I happen to use
something similar:

data:text/html;charset=ISO-8859-1
%3C!DOCTYPE%20html%20PUBLIC%20%22-//W3C//DTD%20HTML%204.01//EN%22%20%22http://www.w3.org/TR/html4/strict.dtd%22%3E%3Chtml%3E%3Chead%3E%3Ctitle%3ERFC %20Search%3C/title%3E%3C/head%3E%3Cbody%3E%3Cform%20action=%22http://www.rfc-editor.org/cgi-bin/rfcsearch.pl%22%20method=%22post%22%3E%3Cinput%20t ype=%22hidden%22%20name=%22searchwords%22%20value= %22%s%22%3E%3Cinput%20type=%22hidden%22%20name=%22 filefmt%22%20value=%22txt%22%3E%3Cinput%20type=%22 hidden%22%20name=%22num%22%20value=%2225%22%3E%3C/form%3E%3Cscript%20type=%22text/javascript%22%3Efunction%20isMethodType(s)%20%7B%2 0return%2
(s%20==%20%22function%22%20%7C%7C%20s%20==%20%22ob ject%22)
%20%7D%20var%20o%20=%20document;%20if%20(o%20&&%20 (o%20=%20o.forms)%20&&%2
(o%20=%20o%5B0%5D)%20&&%20isMethodType(typeof%20o. submit))%20o.submit()
%3C/script%3E%3C/body%3E%3C/html%3E

(This is initiated from the client side, of course.)
PointedEars
Jan 3 '06 #3

P: n/a
On 2006-01-03, ds******@gmail.com <ds******@gmail.com> wrote:
Hello.

Can anybody solve this problem?

I am using a server-side language (PERL) to *try* to POST data to a
HTTPS login script that doesn't have a standard "submit" button. The
form appears to use javascript to submit the document via the browser's
DOM.

<form action='loginScript.cgi' method="post" name="loginForm">
<input name="userid" />
<input name="password" />
<a href="javascript:document.loginForm.submit()" >
<img src="someImage.gif" >
</a>
</form>

Any ideas on how to use a server side language (PERL preferably) to
submit via this javascript dependent form?


AFAICT replacing the javascript link with

<input type="submit" value="login" >

produces the exact same request, so there's nothing magical about that form.
Is there a libcurl binding for PERL? (I mainly use PHP)

Bye.
Jasen
Jan 4 '06 #4

P: n/a

Lee wrote:
ds******@gmail.com said:

Hello.

Can anybody solve this problem?

I am using a server-side language (PERL) to *try* to POST data to a
HTTPS login script that doesn't have a standard "submit" button. The
form appears to use javascript to submit the document via the browser's
DOM.


figured it out.. false alarm... it was a lack of cookie handling
afterwards that kept me from getting in... thanks anyway.

Jan 10 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.