Password scheme/Persistent session...

[krakle]

Well for one thing you condradicted yourself elsewhere.

I see no contradiction in my posts.

You said that
looking up names that start with Z would take longer than names that start
with A (or words to that effect).

This is true. Linear.

However, that would only be true if the
data was sorted, which would imply that apache does something smarter with
the data in .htpasswd than simply doing a "linear style look up".

Read the documentation. Better yet, add 100,000 users to a plaintext
..htpasswd file. Have fun with it

I wouldn't see any reason to assume that apache does
linear lookups in the first place.

Why ASSUME? Apache does linear lookups on .htpasswd. If you wanted it
NOT to there is a seperate mod that enables you to use a Berkely DB.

it is just as possible that the files
are (for example) cached in memory in some kind of structure that provides
extremely fast lookup.

Possible? You are just guessing... And that's not how .htpasswd
works...

 

[gnari]

Tad McClellan <[email protected]> wrote in message

Because mod_perl IS CGI? Actually buddy, mod_perl ISN'T CGI...

if you are using mod_perl, you might want to take a look at
Apache::AuthenDBI

gnari

 

[krakle]

if you are using mod_perl, you might want to take a look at
Apache::AuthenDBI

gnari

Thank you.

 

[krakle]

The fact that you mentioned .htpasswd

I said "Please don't direct me to .htpasswd". My post wasn't
pertaining to .htpasswd.

indicates that you were
considering a method of authentication. Apache supports various
authentication techniques. You haven't shown any cause yet why one of
them would not meet your requirements.

I guess you didn't read WHY I don't want .htpasswd. I mentioned 1. it
does linear style lookups and this will be a very populated members
section. 2. I need MORE control over a session for expiration,
tracking etc. I think it's very clear WHY .htpasswd DOESN'T meet the
requirements.

You state, without showing your working, that you "need a session".

If that's truly so, then why were you considering a method of
authentication - which by no means defines a session? So you
in effect contradicted yourself, while bringing in what you claimed to
be a reason ("linear search") that was completely irrelevant to the
contradiction which you had produced.

If you consider that a contradiction be my guess but isn't this
"contradiction claim" more irrelevant than this "linear search". No
offense, but that was ridiculous...

On the basis of what you've posted so far, I'd say that readers here
are entitled to conclude that you haven't yet reached a proper
decision about what to implement;

How did you come up with that? Ofcourse I have. I'm doing work for a
populated site. I'm using mod_perl. I need to create a members
section. I need a persistent session with each user logged in to
mantain state to keep them logged in within the restricted area. So I
asked whether there was a Perl module to keep state without using
cookies.

so it's hard to believe that you're
ready for Perl-specific advice on how to implement it. Of course I
could be wrong - obviously we don't have the full background to your
problem, so folks have to respond on the basis of what you chose to
post.

I didn't ask on how to implement it. I KNOW how to implement the pass
protection. I just was curious if there was away OTHER than using
cookies or mungled URLs to mantain state. For instance, ASP has a
function specifically for this...

It didn't appear to be about programming in Perl, either, you know.

I did ask is there away to mantain state IN THE Perl LANGUAGE without
cookies perhaps through a module... IF I was to ask "How can one
mantain state without cookies" in a non-language specific newsgroup
i'm POSITIVE someone would refer me to ASP.

 

[Richard Morse]

I didn't ask on how to implement it. I KNOW how to implement the pass
protection. I just was curious if there was away OTHER than using
cookies or mungled URLs to mantain state. For instance, ASP has a
function specifically for this... [snip]
I did ask is there away to mantain state IN THE Perl LANGUAGE without
cookies perhaps through a module... IF I was to ask "How can one
mantain state without cookies" in a non-language specific newsgroup
i'm POSITIVE someone would refer me to ASP.

The Perl language has no inherent way to do this. No language does.
There might, however, be modules available that help do this.

However, by the nature of the way HTTP works, you somehow have to have
the client maintain some kind of key which you use to select which
session it is representing.

ASP uses cookies by default to keep track of the session id. However,
if cookies aren't available on the client, it probably falls back to URL
rewriting. There are no other available ways to maintain the session
identifier without creating undesirable situations. Basing it off of IP
is not good, with the multitude of NAT servers.

If you wish to maintain session state without using cookies, you too
will have to fall back to URL rewriting.

HTH,
Ricky

 

[John W. Kennedy]

I never asked how the web works or any sort of question to that
nature. It was a question pertaining to sessions in mod_perl. Yes it
will be used for a web site obviously but it DOESN'T make sense to ask
a PERL question in a regular newsgroup dealing with the web that
doesn't relate to PERL... Why is this so hard for you guys to
understand...

We understand perfectly. You are asking a question about how the web
works in a Perl group. I suppose you also ask questions about Chebyshev
polynomials on comp.lang.fortran, double-entry bookkeeping in
comp.lang.cobol, and catchwords and press figures in comp.lang.postscript.

By the way, you're also abusing the web with your design; cookies are
how sessions are supposed to be maintained; that's why they were
invented. So essentially you're going to alt.fan.circularsaws and
asking how to use your chisel to drive Phillips-head screws.

Once you have found out someplace /appropriate/ how you might succeed in
thus shooting yourself in the foot, and you have read the relevant Perl
documentation, maybe you can get someone here to help you shoot yourself
in the foot with Perl.

I'll even give you a hint: SCARLET O’NEIL.

 

[dan baker]

I'm creating members only service with perl (I will be using mod_perl)
for a busy web site. I need to create a Members Area that is pass
protected.
---------------------------

cookies are not inherently evil, and might be the only real solution
for reasonably secure web-based "member's login" areas...you just have
to be thoughtful in how you expire the "session" and what you expose
in the cookie. People surfing from home might want to stay "logged
in", whereas you want to be sure to expire sessions that might be on
computers in public places.

You COULD try to do something with IP addresses, but not many people
have static IPs.

I ended up using a scheme in a similar situation that sets a cookie
which is a combination of the username, the time, and the user's
encrypted password. comparing it to what I have stored server-side. if
everything doesn't match, or if the time is "too old" then I kick'em
out to re-login where I can check against the password, etc. The nice
thing about managing it this way is you can do nice things like email
passwords (only to the user's previously defined address) when they
forget, etc.

d

 

[krakle]

We understand perfectly. You are asking a question about how the web
works in a Perl group.

OR I asked how can you mantain state in Perl to make a session with
out the use of cookies. That's not a question asking how the web
works. It's a Perl question. To say such a thing just proves your
ignorance after I repeatedly asked the question. Wow...unbelievable.

 

[krakle]

You COULD try to do something with IP addresses, but not many people
have static IPs.

I considered that but then proxies hold many people on one IP aswell
as some networks... Plus dynamic IPs change every connection...

I ended up using a scheme in a similar situation that sets a cookie
which is a combination of the username, the time, and the user's
encrypted password. comparing it to what I have stored server-side. if
everything doesn't match, or if the time is "too old" then I kick'em
out to re-login where I can check against the password, etc. The nice
thing about managing it this way is you can do nice things like email
passwords (only to the user's previously defined address) when they
forget, etc.

What I ended up doing is setting a cookie that md5 encrypted time +
random number + process ID as the session id (sid). Then it looks up
the data of that user in a mySQL table using the SID in the cookie.

Thank you.

 

[Jürgen Exner]

OR I asked how can you mantain state in Perl to make a session with
out the use of cookies. That's not a question asking how the web
works. It's a Perl question. To say such a thing just proves your
ignorance after I repeatedly asked the question. Wow...unbelievable.

Ok, here is a Perl answer. It is even portable to most(all?) other
programming languages:
- As long as the Perl program is not terminated any global variables will
keep its state. Therefore you can use global variables to preserve the state
of the program.
- If you want to preserve a state from one program execution to the next
program execution then typically this is called "data persistence". Two
typical solutions for data persistence are files or databases. Before
terminating the first program execution it writes whatever data you want to
persist into a status file or into a database. The following program
execution reads this information from the file or database and restores the
state.

Now, I doubt that this Perl answer solves your problem, because your problem
is not about data persistence to begin with.
Your problem is about the stateless nature of the HTTP protocol where you
cannot relate one HTTP request to another HTTP request without using some
crutch like e.g. cookies. Your question is about what other crutches are
available to work around this "shortcoming" of the HTTP protocol.

In which way a question about workarounds for the HTTP protocol has anything
to do with Perl or any other programming language is beyond me.

Again: Perl has states, Perl maintains the program state during program
execution, there are many ways to preserve the state of a Perl program
between different program executions. None of this has anything to do with
your problem, YOU DO NOT HAVE A PERL PROBLEM.

jue

 

[krakle]

Because we are morons.

So it seems!

 

[Anno Siegel]

OR I asked how can you mantain state in Perl to make a session with
out the use of cookies. That's not a question asking how the web
works. It's a Perl question. To say such a thing just proves your
ignorance after I repeatedly asked the question. Wow...unbelievable.

Well, Krakle, it looks like you and clpm just don't go together.
Remember your last stint? I do, and it was a shouting match quite
indistinguishable from this one.

So this place is full of idiots who don't know what Perl is and
what it isn't. Draw your conclusions and go away. AND STAY AWAY!

Anno

 

[krakle]

Well, Krakle, it looks like you and clpm just don't go together.
Remember your last stint? I do, and it was a shouting match quite
indistinguishable from this one.

I don't remember such a thing...

So this place is full of idiots who don't know what Perl is and
what it isn't. Draw your conclusions and go away. AND STAY AWAY!

I'm here to stay. Have been for the last 4 years. So why should I stay
away? One thing this newsgroup has to learn is you can scream "This
post doesn't belong in this group" to EVERY question. You can also
redirect them to another newsgroup where you will get the same
response. That's usenet for you. 1 person helps you and 25 write books
on how they won't waste their keystrokes on helping you...

I just find it humorous that if my single post was indeed offtopic
then what do you call the 30 something replies (such as your post)...
On topic?

 

[krakle]

Again: Perl has states, Perl maintains the program state during program
execution, there are many ways to preserve the state of a Perl program
between different program executions. None of this has anything to do with
your problem, YOU DO NOT HAVE A PERL PROBLEM.

None of that had anything to do with my question. Not only did you
waste your keystrokes and valuable(?) time but you went offtopic...

Let's see if we can get 25 more people to write books on why my post
was offtopic. This makes this whole group look like fools.

 

[Jürgen Exner]

Let's see if we can get 25 more people to write books on why my post
was offtopic. This makes this whole group look like fools.

I think this is the proto-typical definition of trolling.

Luckily there is an easy remedy:

*PLONK*

jue

 

[Alan J. Flavell]

What I ended up doing is setting a cookie that md5 encrypted time +
random number + process ID as the session id (sid). Then it looks up
the data of that user in a mySQL table using the SID in the cookie.

Which seems to be no different from what your original proposal had
been at the start of this thread. And I still don't see anything
Perl-specific in it.

Thank you.

You still don't understand how to partition the problem space. After
all this to-ing and fro-ing, you've shown no comprehension of any of
the points that were raised, but simply done more or less what you'd
intended all along. Which may be a solution, if we really knew what
the problem was, but we don't (it's not even sure that you've defined
it yourself).

I'd surmise that many of the more experienced souls around here
consider that a grasp of partitioning a problem, and seeking solutions
to their parts in appropriate places, is one of the more important
things to be learned by anyone who is serious about this stuff.

That's what (AFAICS) a number of well-intentioned folks have been
trying, unsuccessfully, to communicate to you, despite your hostility.
And now that it's failed, you go back into the killfile until the next
round of housekeeping.

ho hum

 

[norfernuman]

krakle wrote: Way back when in 2002 (he's still and idiot)

....

From: krakle ([email protected])
Subject: Re: Hiding the DOS screen
View: Complete Thread (18 articles)
Original Format
Newsgroups: comp.lang.perl.misc
Date: 2002-09-22 12:12:50 PST

blah blah blah... My question got answered and if I want to post again
with out searching I will. You can't stop me. The only thing you can
do is accept that *I will do whatever I want and get whatever I want*.
Get some sun (I imagine you don't know what that is you geeks) and
quit bitching about people posting questions in a newsgroup that is
made up of questions.

Yah yah yah this is not a help desk and questions shouldn't be asked.
Hello you idiots look around this newsgroup every thread is a
question. Don't like it? Go slip on a puddle of aids and crack your
head open.
( bold added by me for emphasis on the attitude )

....

Wow, this same guy still got answers from this group. You all either
didn't know of him, remember him, or your very forgiving. He's got some
nerve even showing his 'face' back here.

Troll, hmm... I'm thinking of harsher terms but why waste it on him.
What goes around comes around.


- norfer

 

[Alan J. Flavell]

Wow, this same guy still got answers from this group. You all either
didn't know of him, remember him, or your very forgiving. He's got some
nerve even showing his 'face' back here.

What you're missing is that the regulars are responding as much for
the potential benefit of the rest of the Usenet audience, as for the
individual who provoked the issue.

 

[John W. Kennedy]

So it seems!

You are obviously ineducable.

*PLONK*

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"

 

[Anno Siegel]

(e-mail address removed)-berlin.de (Anno Siegel) wrote in message


I don't remember such a thing...

I do, and so does Google. Your aggressive arrogance is quite memorable.

I'm here to stay. Have been for the last 4 years. So why should I stay
away? One thing this newsgroup has to learn is you can scream "This
post doesn't belong in this group" to EVERY question. You can also
redirect them to another newsgroup where you will get the same
response. That's usenet for you. 1 person helps you and 25 write books
on how they won't waste their keystrokes on helping you...

Fine. If you want to be known as a self-confessed parasite and pick
useful scraps out of piles of shit thrown your way, be my guest.
I prefer a little respect myself.

I just find it humorous that if my single post was indeed offtopic
then what do you call the 30 something replies (such as your post)...
On topic?

Identifying and eliminating ticks is always on topic.

Anno