On Sat, Apr 22, 2000 at 02:28:44PM -0600, dreamwvr wrote:
hi, most likely you will want to shut down cookies and use another
method as per advisories that currently there is a problem with
javascript and cookies when both enabled. b.t.w. exploder has simular
problems so since javascript is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 2:28 PM -0600 4/22/00, dreamwvr wrote:
to have cookies are a problem these days. besides most clueful users
these days
have cookies turned off..
The percentage of "clueful" users is extremely small. Furthermore,
since the vast majority of
"d" == dreamwvr [EMAIL PROTECTED] writes:
d to have cookies are a problem these days. besides most clueful
d users these days have cookies turned off..
According to what survey? I'd like to see some real numbers before
abandoning a very useful technique.
"I heard it on TV so it must be
On Sat, 22 Apr 2000, dreamwvr wrote:
hi,
most likely you will want to shut down cookies and use another method as per
advisories that currently there is a problem with javascript and cookies when
both enabled. b.t.w. exploder has simular problems so since javascript is nice
to have
On Mon, 24 Apr 2000, Vivek Khera wrote:
"d" == dreamwvr [EMAIL PROTECTED] writes:
d to have cookies are a problem these days. besides most clueful
d users these days have cookies turned off..
According to what survey? I'd like to see some real numbers before
abandoning a very useful
On Mon, 24 Apr 2000, Matt Sergeant wrote:
On Sat, 22 Apr 2000, dreamwvr wrote:
hi,
most likely you will want to shut down cookies and use another method as per
advisories that currently there is a problem with javascript and cookies when
both enabled. b.t.w. exploder has simular
On Mon, 24 Apr 2000, Marc Slemko wrote:
Don't go holding slashdot up as a great example. They is a perfect
example of what not to do. Last I checked, and this is probably still
true, anyone could make a post that, when read, stole the password of the
user reading it if they were logged in
On Mon, 24 Apr 2000, dreamwvr wrote:
usally nothing but now everything as per bugtraq advisory.. what this means is
javascript code is inserted into a cookie that is living on a client and
executed there.. they can therefore read your bookmarks and so on..
I shudder at the thought of all
hi,
actually in order for this flaw to work one must have both enabled
on the browser.. was just giving people a heads up since the topic
was cookies.. and no IMHO cookies are not required to obtain good
info..
On Mon, 24 Apr 2000, Matt Sergeant wrote:
On Mon, 24 Apr 2000, Marc Slemko wrote:
On Fri, 21 Apr 2000, Gunther Birznieks wrote:
At 01:44 PM 4/20/00 -0500, Matt Carothers wrote:
Another big win is that the secure token can persist across multiple
servers.
What would prevent the token from being across multiple servers otherwise?
It's beneficial when compared to a
On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote:
The secure session has the following properties:
*) The user is able to initiate a secure session by providing proper
credentials (i.e., a username and password pair) via a login process.
*) The user is able to terminate the
hi,
most likely you will want to shut down cookies and use another method as per
advisories that currently there is a problem with javascript and cookies when
both enabled. b.t.w. exploder has simular problems so since javascript is nice
to have cookies are a problem these days. besides most
At 09:42 AM 4/22/00 -0500, Michael Schout wrote:
On Thu, Apr 20, 2000 at 12:15:16PM -0400, DeWitt Clinton wrote:
The secure session has the following properties:
*) The user is able to initiate a secure session by providing proper
credentials (i.e., a username and password pair) via a
At 01:44 PM 4/20/00 -0500, Matt Carothers wrote:
On Thu, 20 Apr 2000, DeWitt Clinton wrote:
5) The secure token is associated on the server side (preferably on
another tier, such as a database) with the user identification token.
Additionally, to support secure session timeouts, the
PROTECTED] [EMAIL PROTECTED]
Date: 20 April 2000 10:55
Subject: Re: Implementing security in CGI
This is a question for comp.infosystems.www.authoring.cgi.
But since I'm here...
I would check for the cookie every time a request is made. If you use
Apache::Session there will be a separate session
Hy,
why do you use cookie's ??? A lot of people hate them.
I think a much better Idea is to put your sessionID in the PathInfo
of every requested URI.
So after the login your CGI generates a SessionID. Lets say your
CGI has the URI http://domain/mycgi.
After the login the cgi's output is just a
Yeah it works on all the clients, but it's a pain in the ass to do relative
URLs when manipulating PATH_INFO. So it's not necessarily trivial to
program and maintain unless you pass everything through a monolithic CGI.
Of course, on Apache it may be easier by using mod_rewrite to manipulate
about this news group. I'll keep tabs on this
group.
Murali
-Original Message-
From: Jeff Beard [EMAIL PROTECTED]
To: Differentiated Software Solutions Pvt. Ltd. [EMAIL PROTECTED];
[EMAIL PROTECTED] [EMAIL PROTECTED]
Date: 20 April 2000 10:55
Subject: Re: Implementing security in CGI
At 05:36 PM 4/20/00, Differentiated Software Solutions Pvt. Ltd. wrote:
a) [...] then do we have a
security hole? Is not the user assuming that by killing the browser we are
exiting the system !!
Yes there is a security risk. HTTP is an insecure protocol. You can use the
ideas that have been
Hi,
Interesting thread and interesting question.
It makes sense to start with the requirements for what it means to
implement those secure features. My requirements have an obvious
e-commerce bias, and should probably be heavily reviewed by anyone
thinking of using this design for
On Thu, 20 Apr 2000, DeWitt Clinton wrote:
5) The secure token is associated on the server side (preferably on
another tier, such as a database) with the user identification token.
Additionally, to support secure session timeouts, the current time
must be recorded.
An easy way to
not
exist.
Am I right ??? Please help.
Thanks,
Murali
-Original Message-
From: Gunther Birznieks [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: 19 April 2000 18:44
Subject: Re: Implementing security in CGI
Apache::Session could be useful. But the session key
Murali,
Yes I have a site that uses the exact mechanism that you state. As Jeff
said though, you should have an "auto-logout" feature. I implemented this
as a cron job that runs every 30 minutes and checks each session for the
last time it has been accessed. I'm sure there are other ways to
23 matches
Mail list logo
