«

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

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)

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 (199.

[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

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.
>
> <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 form doesn't depend on javascript, only the submit mechanism does.
For purposes of replicating it on the server, it's simply a form that
POSTs the userid and password.

Lee wrote:
> 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.