Hi, all --
...and then David T-G said...
%
% I guess I need a primer on cookie usage. I've read the manual regarding
[snip]
All has become clear, or at least only murky :-)
I was having trouble wrapping my head around how to start cookies (a la
sessions) and then check to see if I had a
-Original Message-
From: David T-G
Sent: Sunday, May 9, 2004, 6:09:06 AM
Hi, all --
I guess I need a primer on cookie usage. I've read the manual regarding
setcookie and have gone back to look at everything having to do with
cookies on this list in the past few months (it seems that
John Taylor-Johnston mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 11:40 AM said:
Can someone recommend a good URL on cookies and security issues
please? I can program them, but am told I'm putting others at risk,
forcing people to use cookies on my site.
I guess it depends on
* Thus wrote John Taylor-Johnston ([EMAIL PROTECTED]):
Can someone recommend a good URL on cookies and security issues please?
I can program them, but am told I'm putting others at risk, forcing people to use
cookies on my site.
Being online is a risk, or even crossing the street is a risk
Nothing much. Been receiving flack about forcing people into cookies. Much
misunderstood info about cookies. I need an URL to pass on for extra reading, as
rebuttal.
Chris W. Parker wrote:
John Taylor-Johnston mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 11:40 AM said:
Can
It's your site isn't it? -lol
J
-Original Message-
Nothing much. Been receiving flack about forcing people into cookies.
Much misunderstood info about cookies. I need an URL to pass on for
extra reading, as rebuttal.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
We use a standard disclaimer:
2. Use of Cookies
Like many websites, we use cookies to maintain certain information about
you while you are visiting our website. However, we do not share the
contents of our cookies with any third party, under any circumstances.
Should we allow a third party to
--- John Taylor-Johnston [EMAIL PROTECTED] wrote:
Can someone recommend a good URL on cookies and security issues
please? I can program them, but am told I'm putting others at risk,
forcing people to use cookies on my site.
I have a free chapter about cookies from HTTP Developer's Handbook on
--- Marco Tabini [EMAIL PROTECTED] wrote:
However, we do not share the contents of our cookies with any third
party, under any circumstances.
I'm no lawyer, but that seems like a risky statement. There are many
circumstances that can cause the contents of the cookies you set to be
disclosed to
Chris Shiflett wrote:
--- Marco Tabini [EMAIL PROTECTED] wrote:
However, we do not share the contents of our cookies with any third
party, under any circumstances.
I'm no lawyer, but that seems like a risky statement. There are many
circumstances that can cause the contents of the cookies you
Marco Tabini mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 1:31 PM said:
But if the browser causes the information to leak, we did not share
(or disclose) it--the user did, through action or inaction (e.g.: not
patching his or her browser).
Your bank won't share your money with
Actually it's more like the bank storing your money in a safe with glass
walls.
Sure the bank stored it, and stored it securely (it was behind glass
wasn't it?) but someone could easily break the glass and steal all the
money.
The argument from the customer would be The company I put my trust in
Chris W. Parker
on Tuesday, October 21, 2003 2:35 PM said:
Actually it's more like the bank storing your money in a safe with
glass walls.
Sure the bank stored it, and stored it securely (it was behind
glass wasn't it?) but someone could easily break the glass and steal
all the money.
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
responsibility to
Joseph Bannon wrote:
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the site. It is thus their
--- Marco Tabini [EMAIL PROTECTED] wrote:
IMHO, by storing the user's name and password in a cookie, you may be
exposing that information to unnecessary risks by letting it go back
and forth continuously on the Net (assuming, of course, that you're
not under SSL and/or are using some
Marco Tabini wrote:
Joseph Bannon wrote:
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to membership only parts of the
If we're into analogies, how about a cookie containing username/password being
much the same as leaving the keys to the house under your doormat? If someone
knows that this is a common practice, they can find them and gain access to
your house.
As I understand it (and I am not a lawyer) the
John W. Holmes wrote:
Marco Tabini wrote:
Joseph Bannon wrote:
I think it's the responsibility of whomever is holding the key (ie, the
username and password). When a user logs into my site, I put their
username and password in a cookie. I then check those cookies to allow
them access to
John W. Holmes wrote:
You're not even allowed to use persistant cookies in public government
sites unless you get permission from the Secretary of the Defense.
Hi, this is interesting. Can you post the guidelines?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
On Tue, Oct 21, 2003 at 04:48:13PM -0500, Joseph Bannon wrote:
:
: I think it's the responsibility of whomever is holding the key (ie, the
: username and password). When a user logs into my site, I put their
: username and password in a cookie. I then check those cookies to allow
: them access to
--- Marek Kilimajer [EMAIL PROTECTED] wrote:
John W. Holmes wrote:
You're not even allowed to use persistant cookies in public
government sites unless you get permission from the Secretary of
the Defense.
Hi, this is interesting. Can you post the guidelines?
I've never heard of the
Marek Kilimajer wrote:
John W. Holmes wrote:
You're not even allowed to use persistant cookies in public government
sites unless you get permission from the Secretary of the Defense.
Hi, this is interesting. Can you post the guidelines?
Quote: This policy will be clarified to make clear that
Chris W. Parker wrote:
John Nichel mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 3:50 PM said:
The
only thing I store in a cookie is a userid and a randomly generated
number, and that's only if the site is to have a 'remember me'
function so you don't have to login everytime. Even in
John Nichel wrote:
Chris W. Parker wrote:
John Nichel mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 3:50 PM said:
1. Create a random ID and store it with the users record in the db.
2. If the user chooses to be remembered, stick the random ID into a
cookie.
3. When a user hits a
John W. Holmes wrote:
snip
Chris W. Parker wrote:
Here's a thought:
How about adding an abitrary number (let's say 241757219) to every users
userid and then storing that number as the random id?
So let's say the first user comes along and is given the userid 1. We
then create their random id by
John W. Holmes mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 5:30 PM said:
Not a good method. If I get on your site and see my cookie has the
value 241757219 in it, I just need to subtract one from the number
and revisit your site. Now I'm the user who registered before me.
Using
Chris W. Parker wrote:
John W. Holmes mailto:[EMAIL PROTECTED]
on Tuesday, October 21, 2003 5:30 PM said:
Not a good method. If I get on your site and see my cookie has the
value 241757219 in it, I just need to subtract one from the number
and revisit your site. Now I'm the user who
--- John W. Holmes [EMAIL PROTECTED] wrote:
So let's say the first user comes along and is given the userid 1.
We then create their random id by adding 241757219 to their userid.
We get a random id of 241757220. Then within the login page I can
subtract 241757219 from their random id
On Wednesday 22 October 2003 08:47, Chris W. Parker wrote:
on Tuesday, October 21, 2003 5:30 PM said:
Not a good method. If I get on your site and see my cookie has the
value 241757219 in it, I just need to subtract one from the number
and revisit your site. Now I'm the user who
--- Chris W. Parker [EMAIL PROTECTED] wrote:
Not a good method. If I get on your site and see my cookie has the
value 241757219 in it, I just need to subtract one from the number
and revisit your site. Now I'm the user who registered before me.
Using the rand() or uniqid() method above
On Wednesday 22 October 2003 08:37, John Nichel wrote:
Oh sure, figure out a way to circumvent this. What the hell are you
trying to do, help people here? hehe
Your fault for crowning him king ;-)
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems
Jason Wong wrote:
On Wednesday 22 October 2003 08:37, John Nichel wrote:
Oh sure, figure out a way to circumvent this. What the hell are you
trying to do, help people here? hehe
Your fault for crowning him king ;-)
I knew that would come back to bite me.
--
By-Tor.com
It's all
On Fri, May 30, 2003 at 11:01:26PM -0700, Evan Nemerson wrote:
Send a session ID to the user in a cookie, then lookup that ID in a database
on the server. It's extremely difficult to guess random session ID's (don't
just increment them!), and if you have a session timeout, you're pretty much
Again, It's not perfect, but I don't think anyone has come up with a better
way.
It's called session hijacking, and it is a great reason to use SSL. However,
there's still the issue of cross-site scripting, which can really only be
prevented by smarter coding.
Even then there are issues. For
The short answer is that if you're worried about security, don't store a uid
and pwd in a cookie on the client... banks don't do it, for example.
It's also common for the uid to be remembered, but not the pwd.
From what I can see happening on the big sites, you give the user the
option to be
Send a session ID to the user in a cookie, then lookup that ID in a database
on the server. It's extremely difficult to guess random session ID's (don't
just increment them!), and if you have a session timeout, you're pretty much
set.
It's not perfect, but I don't think anyone has come up with
Ken
Do *not* use hidden form statements or cookies to store any SQL this is
extremely dangerous and a relatively simple hack could destroy your database
completely!
By all means use hidden form fields to store row ID values but your PHP
scripts should treat all user input data via
dose anyone how to send a ping in local network
thanks
Paul Marinas
Technical Support
RDS Craiova
Phone: +402-51-410-194
Mobile: +407-22-451-439
Fax:+402-51-416-579
www.rdsnet.ro
.
Privileged/Confidential Information may be contained
Try the system() or passthru() functions...
Rich
-Original Message-
From: Paul Marinas [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2002 13:09
To: Rich Gray
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [PHP] using cookies
dose anyone how to send a ping in local network
thanks
--- Ken Nagorski [EMAIL PROTECTED] wrote:
I have never used cookies before, however I am trying to
implement them to make things a little more secure. Rather
than passing a sql statement via a hidden input tag I am
setting a cookie.
I think someone else already mentioned this, but let me
It seemed I thought it should work at least. But it does not on PHP4.0.4pl1.
Try following code
?php
$user = empty($HTTP_GET_VARS['user']) ? '' : $HTTP_GET_VARS['user'];
$pw = empty($HTTP_GET_VARS['pw']) ? '' : $HTTP_GET_VARS['pw'];
$cookieuser =
42 matches
Mail list logo
