First of all, why do I need cookie? My SIDs are 32bytes long so guessing
it could be a bit of a PITA. And if someone would sniff the SID, he
could set his browser's cookies to send this SID. So I don't understand
how cookies might help? [especially that they are sent from a
potentially
On Thu, 27 Dec 2001, Wojciech Kocjan wrote:
First of all, why do I need cookie? My SIDs are 32bytes long so guessing
it could be a bit of a PITA. And if someone would sniff the SID, he
could set his browser's cookies to send this SID. So I don't understand
how cookies might help?
It's about 5 minutes of work for an experienced user - modify /etc/hosts
or c:\winnt\hosts.sam to point www.domain.com to localhost and write a
small script that'd set a session cookie.
Also, my IE5 stores all the cookies as plaintext in this directory:
C:\Documents and Settings\zoro\Cookies
On Thursday, December 27, 2001, at 05:40 AM, Wojciech Kocjan wrote:
I think that anything the user supplies cannot be trusted and as such
sessions are a real problem to make secure.
You and I are in violent agreement on this point. This is the least-risk
strategy; it is also the hardest to
On 2001.12.27, Peter M. Jansson [EMAIL PROTECTED] wrote:
The one way cookies can help avoid hijacking is in a
security-through-obscurity sense, since it's more difficult to set a
cookie using the conventional command-line tools, or even through browsers
(browsers I use allow viewing and
Hmmm.
As I mentioned before, I use 32 bytes long mostly random SessionIDs -
that is, there is no ID related to database. The only way to hijack a
session is to guess (or probably sniff :) the 32byte ID...
I have no idea how to effectively protect against that.
Dossy wrote:
On 2001.12.27,
On 2001.12.27, Wojciech Kocjan [EMAIL PROTECTED] wrote:
As I mentioned before, I use 32 bytes long mostly random SessionIDs -
that is, there is no ID related to database. The only way to hijack a
session is to guess (or probably sniff :) the 32byte ID...
I have no idea how to effectively
I can't put the whole thing together off the top of my head, and I'm a
little busy this week, but I think the risks include the following:
- guessing a session ID
- replaying a session ID
- accidentally generating a duplicate session ID
The server should take a unique session ID, a per-request
Hello,
How can a module X expose API's to other modules?
I can think of the following possiblities:
A) Add Tcl commands, so the other modules could execute the commands
B) Register for URL(s), maybe one URL with parameters for which function and
the function parameters encoded in the URL, or
+-- On Dec 27, Ramin Naimi said:
Hello,
How can a module X expose API's to other modules?
Hmm. I thought a module could refer to another module's exported C
functions directly. Have you tried it?
For C modules, simply create the C functions you want exposed from your
module as externs and call them Ns_SomeName. Just make sure you don't
conflict with a C function name that already exists in the core or in other
modules. You do this by prepending something that you think is going to be
On 2001.12.27, Rob Mayoff [EMAIL PROTECTED] wrote:
+-- On Dec 27, Dossy said:
Netscape has the option of allow all cookies or allow cookies
that get sent back to the originating server. So, if you just
set allow all cookies then send your browser a set-cookie where
domain= the
12 matches
Mail list logo
