Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Is there any way using the HTTP/WWW modules to sign into a web site that has a login-timeout (expiration period of inactivity) and keep the page active indefinitely until the script is loaded via the browser and have the current login cookie passed to their computer?

In short, there is a site that has a timeout period and it's really hard to log into during the day. It would be easier to have a script on my web site log in and keep the account active until I can come back during the night and login without any problems.

Any way this is possible?

Replies are listed 'Best First'.
Re: keep a user signed in
by GrandFather (Saint) on Nov 13, 2005 at 19:54 UTC

    Just so I understand this: you want help to write a script so that you can "lock" a slot on a busy site for, possibly many, hours until you can personally get to it, meanwhile denying access to other people who may be trying to access the site too? Why don't you give us the URL so that we can all write robots and provide a complete denial of service attack on the site?

    We could turn it into a competition to see who can write the robot most effective at blocking the site. Would you like to create the rules and post them here? Maybe we could judge it by earning one XP-- for each successful attack with the largest decrease in XP at the end of some specified time being the winner (or do I mean loser)?


    Perl is Huffman encoded by design.

      My guess is that, no, that's not quite what the OP wants to do. The OP's question seems to me to be one of keeping a login valid - usually this doesn't prevent anyone else from logging in. For example, just because I forget to close the fullpage CB window on perlmonks doesn't mean that you can't log in. But I will get continually updated cookies which keeps me from being logged out (if there was such a timeout scheme available).

      The OP wants some way of doing that on a site that doesn't have an auto-refresh like the fullpage CB here, which means that the browser can't do it automatically (well, not easily - I'm sure that with some frames and javascript you may be able to pull it off).

      What was mentioned in the CB at one point is the idea of an HTTP proxy. I don't even recall who mentioned it. Rather than going to the site, you go to the proxy. The proxy would be written with WWW::Mechanize for the continuous pinging of the server, and HTTP::Proxy for proxying (probably - maybe HTTP::Daemon, not sure), and something for cookie support. When the browser hits the proxy, the proxy returns back the cookie with the data.

      Doesn't really sound like a lot of fun, and I'm just not sure why the OP can't just login at night - is the ability to log in only available while you're at work?

        OP: ... and it's really hard to log into during the day. It would be easier to have a script on my web site log in and keep the account active until I can come back during the night ... .

        That strongly implies to me that it is a site which allows a limited number of logins (presumably to avoid clobbering the server) - hence the strong reaction. I guess OP could reply and tell us I am wrong, in which case I will have earned any -- I get. :)

        If OP's story is really good I'll even appologise, ++ the reply and point OP at a suitable module.


        Perl is Huffman encoded by design.
      Had to downvote. You can't approve a SOPW and attack it the way you did. If you thought the OP was using it for that purpose, it should have been considered instead of approved.

      You're pretty much saying it's okay but it's not.

      Now I am indifferent about this but then again, I didn't approve and then attack.

      To get back on topic and to answer the question. It is possible and really not that hard to do. You should first check the time out period and write your bot NICELY so it only goes active when it needs to and not any more.

        I approved it because it was an Anonymous Monk post and the original poster (assuming that he is not a monk in hiding) would otherwise not see see the original post (or indeed see any replies that may be made) and may be tempted to post again.

        In general beating on a limited resource in this fashion is a Bad ThingTM. Note that any bot in this case is bad because it is keeping a channel locked, but unused, and is therefore denying other users access so that OP can come along, without regard to anyone else, at his leisure and use the limited resource. The pathalogical case comes when all the "users" are bots and no-one actually uses the site. Do you want to encourage that?


        Perl is Huffman encoded by design.
        I think that approving a post to PM and agree its contents are two quite different and somehow unrelated things.

        The OP was quite in-topic and not offensive. This is something that IMHO qualifies a node for approval in the PM sense - freedom to speak. OTOH, I could be strongly against what the OP contains, and I like to think that there's space to express one's thoughts. Again, freedom to speak.

        IMHO, that "competition" stuff was a bit exagerated independently on who approved the OP - but this is only my humble opionion.

        Flavio
        perl -ple'$_=reverse' <<<ti.xittelop@oivalf

        Don't fool yourself.
        Approving is about publicity, not agreement.
Re: keep a user signed in
by inman (Curate) on Nov 14, 2005 at 14:12 UTC
    Yes - you can use an LWP based application (i suggest using WWW::Mechanize) to login and refresh the page every 10 minutes or so. You need to store the login cookies in your browser cookie store. This is either a text file in the case of Mozilla, Firefox etc. or an individual file in the cookies directory specified by Internet Explorer.

    The LWP library has a number of Cookie Jar subclasses to support the main cookie store formats. The trick is to subclass the cookie jar to write out session cookies (that have no expiration time) such that they expire at some point in the future E.g. later today.

    This is something that I do on from time to time to test an automated login for website indexing. I wouldn't suggest that you do this on a regular basis. Read the comments from the other monks about potential issues with this approach. You may wish to restate the problem so we can help you find a better solution.