in reply to Perl/Cookie and data transmission

Do you have users who can connect, login, and sucessfully update the page they are on / other info?

It's a very different problem if there are no users who can use the system properly vs. one user with an issue. If it's just the one user, I promise you that it's something related to just their user account, or their browser, etc.. and it simplifies things immensely.

On the other hand, if no one's user account is updating properly, and never has been, your debugging should focus on site logic as opposed to user data and platform stuff for the one guy.

Could you explain more about what they are trying to do when they 'submit any further data'? I am thinking you mean change pages, but more detail might help find the problem.

Replies are listed 'Best First'.
Re^2: Perl/Cookie and data transmission
by Sylvyr (Initiate) on Jun 01, 2005 at 18:58 UTC
    Sorry about the mix-up.

    All the other users have been able to connect AND navigate the site with the exception of the one client in question, in their office.(I can connect and navigate using their login from any other location)

    The "client in question" can connect to the main page via the login form but is unable to navigate from there.
    It seems like whenever they try to submit any arguments it doesn't work. ie: client.cgi?arg1=123&arg2=321

    Are there any browser, software, or even firewall specific settings that would prevent someone from submitting data in the form of an argument? Or maybe any other software/hardware specific settings? We've tried from multiple computers in their office and had the same results so I'm beginning to think it could be in their network.

[reply]
      It sounds to me like it could very likely be their network if only computers from inside their network (and more than one of them) are having the problem. Especially if the login works from other locations.

      As for what exactly could be the problem, here are a couple guesses..

      Maybe your client in question is running through a proxy that doesn't want to update or pass through his cookies properly.

      Maybe his browser at work has higher security settings than the machine you tested his login on elsewhere, or the settings are triggered differently based on where you login from -- for example, if you login from the same subnet as the server, perhaps that loosens restrictions.

      I can't really think of many other network-related settings. Get some debug info on the server side to help narrow down the issue: make scripts that will just dump their args and cookies back to the browser and you can see exactly what is being updated and when.

      Hope that helps.

      - P

[reply]
        UPDATE:

        Thanks for your help.

        I switched the system around a little and instead of storing the session ID in a cookie, I'm passing it through the URL in stead. Access wise, everything is working fine.

        I was wondering if anyone had any tips on beefing up the security. I know having the SID in plain sight isn't the safest thing in the world, but I've also taken a few minor steps in keeping it secure.

        The creation of my SID is a very reliable, random, process. So I think I've done well there. I'm also checking the user's IP against the person who originally logged in. (I know this can be troublesome with proxies and what not, and I also know it's possible to spoof an IP rather easily in a browser.)

        So with that said... Any security suggestions would be great.

[reply]

In Section Seekers of Perl Wisdom