The simple way is IMHO the right way:
Login by submitting the login/pass on the right page.
You'll get a session_cookie,a session id and/or another hidden field.
the cookie will be managed automagicallt by LWP, you'll have to parse
the HTML code returned to get the optionnal idetification params(id-session appended/posted to url or hidden field.)
The 'get/post' pages feeding the needed values (nothing to do for the cookie, LWP is great enough to do it for you)
You could look at this post to get an idea.
But please post your code for I can give you a more precise answer.
(beccause I gave you the more common methods to authenticate a user
though his navigation, but there are a lot of other ways (Referer, UserAgent checking...))
| [reply] |
Thanx a lot!
Found a 'Set-Cookie' in the headers. So now I have to give it back to the server.
I have to apologize my bad description. The program will be used to put things from a frendly site to my boss' soppingbag-application, which is a standard one he bought.
In order to not causing any other bad intentions, the script will be byte-coded and only be on one location, in our cgi-bin directory.
| [reply] |
Unless you 1) know how the session_var is generated on the other server side, or 2) collect enough legit session_vars to determin the method of generation (brute forcing it), there's no way of doing it, particularly if session_vars include time information in addition to userid and state.
I would also advice some potental caution given that you seem to be trying to go at an e-commerce site that is not yours; not only have courts ruled in favor of e-commerce sites to prevent 'bots' from collecting the same information but in a different display as with Ebay and meta-auction search engines, but I can see a whole host of other problems related to AUPs, the DMCA, and more in trying to decipher that session_var even for a legitamite use. One good example for your case: imagine if you could figure out the session_var structure, and it only stores the userid as a way to identify the user. Since you're playing with a shopping bag application, you could theorhetically maliciously fill any user on the site with goods they don't want via this remote script, and cause a lot of harm. I'm not implying that you're trying to do this here, but there's potental for abuse if your script got into the wrong hands.
Basically, I'd avoid trying to do anything automated with sites or scripts that involve finacle transactions in any way, as it could do more harm than good in the end.
| [reply] |