|
Re: Cookie not being set
by grep (Monsignor) on Jun 24, 2002 at 04:26 UTC
|
Have you tried other browers? Are you using IE6?
IE6 with the default security setting (or anything above Low Secuity) will reject cookies from site without a P3P policy and P3P CPP headers.
If you do not have a P3P policy (an unapproved standard deemed necessary by our malevolent dictator in Redmond) for your site you should (or your users will experience the problem I stated above). You can readup on P3P at W3C. W3C also provides a P3P Validator
As a side note - do not store usernames and passwords in a cookie, this is a security hole (that has been experienced at some well-know sites :) ). You might want to setup a sessionid for that user and reference (and expire) that id
Ovid's excellent CGI programming course addresses cookies and security concerns
grep
|
Just me, the boy and these two monks, no questions asked. |
| [reply] |
|
|
This isn't entirely accurate. Only third party cookies without a P3P are blocked at the default setting for IE6. It takes a setting of "High" to block 1st party cookies (what this example would be) for a site without a P3P.-caedes
| [reply] |
|
|
do not store usernames and passwords in a cookie, this is a security hole
Could you explain why or point me to a node to look at?
You might want to setup a sessionid for that user and reference (and expire) that id
How would be a good way to go about doing this.Thanks
Joshua
| [reply] |
|
|
Here is one node and another that hits closer to home. Other than that I imagine you can search.
As for you session question - if you are using Apache, Apache::Session IIRC will handle it all for you. If not - a simple setup would be session table in your DB with username, timestamp, and session id. Then check for that sessionid (passed either as a param or cookie) and see if it expired
grep
|
Just me, the boy and these two monks, no questions asked. |
| [reply] |
|
|
There are several reasons why this is a security hole.
- Assuming this is not sent over SSL, someone could sniff the traffic and, since this is sent in plaintext, they can see your user's passwords.
- This is usually stored on the user's computer, so someone else with physical access to their machine can get this data.
- Cross-site scripting attacks can often read cookie data and send it somewhere else, thus allowing yet another way to compromise the user's data.
Never fear, these things become second-nature after you work with the Web for a while :)
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
|
|
Re: Cookie not being set
by little (Curate) on Jun 24, 2002 at 07:25 UTC
|
your call
print header(-cookie=>$ucookie, -location=>$new_url);
is wrong, try this
print redirect( -uri=>$new_url,
-cookie=>[$ucookie]
);
If you want to fullfill that with header() you must also supply a HTTP-Status code, eg. 302 Moved or 303 See Other.
Have a nice day
All decision is left to your taste | [reply]
[d/l] |
Re: Cookie not being set
by Ryszard (Priest) on Jun 24, 2002 at 09:10 UTC
|
Useful tip: Use mozilla. With mozilla you can view the values of the cookies using the browser functionality. You can also make it so it warns if you a cookie is being set.
I've experienced similar problems, my problems were around the domain and path settings..
Also if you're using CGI::Application you might want to use redirect rather than using header.
As previously mentioned, you should never, ever, ever put information in your cookie other than a session id, which is mapped to the user serverside. All the information you require, can and should be stored serverside. | [reply]
[d/l]
[select] |
Re: Cookie not being set
by rdfield (Priest) on Jun 24, 2002 at 10:48 UTC
|
If you're using IE6, you can see the cookie "arriving" at the client by setting the advanced privacy settings (Tools->Internet Options->Privacy->Advanced) to "prompt". This will show a dialog box the first time a cookie is sent to the browser, so you can check the details. I suspect that your domain setting is wrong and the browser is completely ignoring the cookie (ie there will be no prompt). If that is the case try sending the cookie without the domain set and see if the prompt appears.rdfield | [reply] |
Re: Cookie not being set
by caedes (Pilgrim) on Jun 24, 2002 at 04:45 UTC
|
I think we really need more information than you are giving us (such as the rest of your script). My suggestion would be to get a client that can show you the HTTP headers (cURL for instance), and make sure that the script and server are sending the browser exactly what you want it to.-caedes | [reply] |
Re: Cookie not being set
by cLive ;-) (Prior) on Jun 24, 2002 at 08:37 UTC
|
Not this is it?
cLive ;-)
--
seek(JOB,$$LA,0);
| [reply] |
Re: Cookie not being set - FIXED
by Indomitus (Scribe) on Jun 24, 2002 at 16:18 UTC
|
Thanks a lot for everybody's help. I changed over to using CGI rather than CGI::Cookie and I also changed to use redirect rather than header and now everything looks like it's working fine. I don't know it seemed to be working before, that's weird.
btw, I'm not sending the password in the cookie, it's another string that just identifies the user. I only call it userpass since in my original code I was sending the password. I've learned the error of my ways though. | [reply]
[d/l]
[select] |
|
|
Your problem may have been that in the cookie you have to set:
domain => ".whatever.com"
In the browser, if you just have the "whatever.com" without the "www." it won't work. The dot in 'domain => ".whatever.com" requires that a name is in front of "whatever.com".
For example:
"http://www.whatever.com" <-- Will work
"http://whatever.com" <-- Will NOT work
| [reply] |
