Thread: Secure pages
Hi everybody, i have a user login authentication sysytem on my machine here where users may view pages but to do other things the user must login. the login scripts seem to work ok and are based on a "Secure Authentication System" from www.phpbuilder.com. Basically the page where i want people to arrive at upon logging in is at present viewable by anyone who puts the proper url into their browser. how do i keep this and other pages secure from people who havent logged in? Thanks, Paul
if you are using apache web server you can try the .htaccess method. I am
not too familar with it. I am trying to learn it myself, but from what i
gather, you put a file called .htaccess in the dir where your web page is.
the .htaccess file contains a path to the a file where all the user names
and passwords are stored. whenever this dir is accessed, a window pops up
asking for a user id and password.
If anyone has more info on this, please pass it on. I am looking into
using this as well. What i am looking to do is create a web based ftp
application. Where users log into a web screen and can ftp files to the
server into a certain directory own by them. I am storing the file paths
and descriptions in a postgresql db and using php for the ftp process. Can
I use .htaccess with this? Can I have someone log into the web page using
.htaccess and passing their user id and password into a cookie or variable
so i will know who they are and they don't have to re-type this when they
ftp the file.
Any help would be great.
Thanks,
Tim.
Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
12:20:57 PM
Sent by: pgsql-php-owner@postgresql.org
To: pgsql-php@postgresql.org
cc:
Subject: Secure pages
Hi everybody,
i have a user login authentication sysytem on my machine here where users
may view pages but to do other things the user must login. the login
scripts seem to work ok and are based on a "Secure Authentication System"
from www.phpbuilder.com. Basically the page where i want people to arrive
at upon logging in is at present viewable by anyone who puts the proper
url into their browser. how do i keep this and other pages secure from
people who havent logged in?
Thanks,
Paul
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
You can do it with a .htaccess file, but why? You've got a very powerful
scripting language to work with...
I do it through a normal html form. Here's how I do it:
1) My login form and logic is all contained within an include file. That way,
I can include it within any page I feel should be password protected and it
automatically does everything.
2) The form action is left blank so that it will simply reload the same page
and take them to the page (and QUERY_STRING [GET] variables) they originally
intended.
3) The form contains a hidden input tag that is the controling variable.
4) I have an if statement within the login.inc.php file that checks to see if
the control variable is set... if it is, I check the login information against
my authentication scheme (usually a database).
5) If the login info is correct, then set cookies indicating that it's good
and let the page load rather than displaying the login box again. If the
login is invalid, display unset your control variable and let the login screen
load again. Of course, you should also display some type of message indicating
that the login failed.
6) Next time they hit the page where the login.inc.php file is included, it
checks the cookies to see if they have already logged in... if so... let them
by without displaying the login screen.
7) Summary of logic:
a) Check to see if "logged in" cookie exists... if so, let them through
b) If cookie doesn't exist, check if control variable (passed from HTML form)
isset
c) If control variable set, check against database, otherwise display login
screen
d) If database check of login info is valid, let them through, otherwise
display login screen
This method is very reusable... because there is no action in the form tag and
all login is within the include file, all you do is include it within any
access controled file and it works seemlessly.
-Dan
: if you are using apache web server you can try the .htaccess method. I am
: not too familar with it. I am trying to learn it myself, but from what i
: gather, you put a file called .htaccess in the dir where your web page is.
: the .htaccess file contains a path to the a file where all the user names
: and passwords are stored. whenever this dir is accessed, a window pops up
: asking for a user id and password.
:
: If anyone has more info on this, please pass it on. I am looking into
: using this as well. What i am looking to do is create a web based ftp
: application. Where users log into a web screen and can ftp files to the
: server into a certain directory own by them. I am storing the file paths
: and descriptions in a postgresql db and using php for the ftp process. Can
: I use .htaccess with this? Can I have someone log into the web page using
: .htaccess and passing their user id and password into a cookie or variable
: so i will know who they are and they don't have to re-type this when they
: ftp the file.
:
: Any help would be great.
: Thanks,
: Tim.
:
:
:
:
: Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
: 12:20:57 PM
:
: Sent by: pgsql-php-owner@postgresql.org
:
:
: To: pgsql-php@postgresql.org
: cc:
:
: Subject: Secure pages
:
:
: Hi everybody,
: i have a user login authentication sysytem on my machine here where users
: may view pages but to do other things the user must login. the login
: scripts seem to work ok and are based on a "Secure Authentication System"
: from www.phpbuilder.com. Basically the page where i want people to arrive
: at upon logging in is at present viewable by anyone who puts the proper
: url into their browser. how do i keep this and other pages secure from
: people who havent logged in?
: Thanks,
: Paul
:
: ---------------------------(end of broadcast)---------------------------
: TIP 2: you can get off all lists at once with the unregister command
: (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
:
:
:
:
:
: **********************************************************************
: This email and any files transmitted with it are confidential and
: intended solely for the use of the individual or entity to whom they
: are addressed. If you have received this email in error please notify
: the system manager.
:
: This footnote also confirms that this email message has been swept by
: MIMEsweeper for the presence of computer viruses.
:
: www.mimesweeper.com
: **********************************************************************
:
: ---------------------------(end of broadcast)---------------------------
: TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
The easiest way in PHP that I have found is to create a file called
validate.php containing the following:
<?
if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
header("Location: http://my.company.com/login");
}
?>
and, after the user has logged in, set a cookie. Then, for each page that
should be for a logged-in user only, just include the validate.php file.
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Tue, 13 Mar 2001 Timothy_Maguire@hartehanks.com wrote:
>
> if you are using apache web server you can try the .htaccess method. I am
> not too familar with it. I am trying to learn it myself, but from what i
> gather, you put a file called .htaccess in the dir where your web page is.
> the .htaccess file contains a path to the a file where all the user names
> and passwords are stored. whenever this dir is accessed, a window pops up
> asking for a user id and password.
>
> If anyone has more info on this, please pass it on. I am looking into
> using this as well. What i am looking to do is create a web based ftp
> application. Where users log into a web screen and can ftp files to the
> server into a certain directory own by them. I am storing the file paths
> and descriptions in a postgresql db and using php for the ftp process. Can
> I use .htaccess with this? Can I have someone log into the web page using
> .htaccess and passing their user id and password into a cookie or variable
> so i will know who they are and they don't have to re-type this when they
> ftp the file.
>
> Any help would be great.
> Thanks,
> Tim.
>
>
>
>
> Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
> 12:20:57 PM
>
> Sent by: pgsql-php-owner@postgresql.org
>
>
> To: pgsql-php@postgresql.org
> cc:
>
> Subject: Secure pages
>
>
> Hi everybody,
> i have a user login authentication sysytem on my machine here where users
> may view pages but to do other things the user must login. the login
> scripts seem to work ok and are based on a "Secure Authentication System"
> from www.phpbuilder.com. Basically the page where i want people to arrive
> at upon logging in is at present viewable by anyone who puts the proper
> url into their browser. how do i keep this and other pages secure from
> people who havent logged in?
> Thanks,
> Paul
>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
On Tue, 13 Mar 2001, Michael Fork wrote:
->The easiest way in PHP that I have found is to create a file called
->validate.php containing the following:
->
-><?
-> if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
-> header("Location: http://my.company.com/login");
-> }
->?>
->
->and, after the user has logged in, set a cookie. Then, for each page that
->should be for a logged-in user only, just include the validate.php file.
Boy that's not very secure...I could find your included file, see what 'Some
Value' is, and then just make my own cookie!
-- Dave
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
not if the include file ends with a .php -- since it is in <? ?>, anybody
acessing the file from a web browser would not be able to see it.
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Tue, 13 Mar 2001, David Olbersen wrote:
> On Tue, 13 Mar 2001, Michael Fork wrote:
>
> ->The easiest way in PHP that I have found is to create a file called
> ->validate.php containing the following:
> ->
> -><?
> -> if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
> -> header("Location: http://my.company.com/login");
> -> }
> ->?>
> ->
> ->and, after the user has logged in, set a cookie. Then, for each page that
> ->should be for a logged-in user only, just include the validate.php file.
>
> Boy that's not very secure...I could find your included file, see what 'Some
> Value' is, and then just make my own cookie!
>
> -- Dave
>
>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
On Tue, 13 Mar 2001, Michael Fork wrote: ->not if the include file ends with a .php -- since it is in <? ?>, anybody ->acessing the file from a web browser would not be able to see it. I misunderstood, I thought you meant that you would put that code in an included file. Which anybody could get at. However the code being hidden doesn't change that I could look for a cookie from your domain, see it's value, and still create another cookie. What you're all looking for is a *session based* authentication system. PHP does this, and you can do it yourself if you have a database set up. -- Dave ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
what i have sone in the past for passwords on web pages is have something
like:
<?
if(md5($MyCookie) != "anencryptedpassword") {
header("Location:http//homepage.com/whatever");
}
that way even if someone got the file and wanted to find out what the "some
value" was it would be encrypted.
There are probably still ways around this, but for the info you are hiding
from people, this is probably safe enough, at least for me it is.
David Olbersen <dave@slickness.org>@postgresql.org on 03/13/2001 02:50:45
PM
Sent by: pgsql-php-owner@postgresql.org
To: Michael Fork <mfork@toledolink.com>
cc: <Timothy_Maguire@hartehanks.com>, Paul Joseph McGee
<mcgee@student.cs.ucc.ie>, <pgsql-php@postgresql.org>
Subject: Re: Re: Secure pages
On Tue, 13 Mar 2001, Michael Fork wrote:
->not if the include file ends with a .php -- since it is in <? ?>, anybody
->acessing the file from a web browser would not be able to see it.
I misunderstood, I thought you meant that you would put that code in an
included
file. Which anybody could get at. However the code being hidden doesn't
change
that I could look for a cookie from your domain, see it's value, and still
create another cookie.
What you're all looking for is a *session based* authentication system. PHP
does
this, and you can do it yourself if you have a database set up.
-- Dave
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Why not ask for a password, encrypt it (with 128bit or something;), check it with the database (which has the encyrpted pwds) and pass the encrypted password from page to page... like: <a href="blah.php?encryptedpassword"> or just a variable which is one indicating that the password was typed in correctly at least once! For the mater of direct accessing you could just check if the pwd (or the var) was passed (is one) and if not -> well no access... You could also use a cookie and check for it (with the encrypted pwd) but (I don't know why) cookies seem preaty unsafe too me :o) just my two cents;)
> Hi everybody, > i have a user login authentication sysytem on my machine here where users > may view pages but to do other things the user must login. the login > scripts seem to work ok and are based on a "Secure Authentication System" > from www.phpbuilder.com. Basically the page where i want people to arrive > at upon logging in is at present viewable by anyone who puts the proper > url into their browser. how do i keep this and other pages secure from > people who havent logged in? > Thanks, > Paul Create a session. If (!(isset($session))) then redirect to login.php or your authentication file. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
>Why not ask for a password, encrypt it (with 128bit or something;), check it
>with the database (which has the encyrpted pwds) and pass the encrypted
>password from page to page...
>
>like: <a href="blah.php?encryptedpassword">
>or just a variable which is one indicating that the password was typed in
>correctly at least once!
>
>For the mater of direct accessing you could just check if the pwd (or the
>var) was passed (is one) and if not -> well no access...
>
>You could also use a cookie and check for it (with the encrypted pwd) but (I
>don't know why) cookies seem preaty unsafe too me :o)
>
>just my two cents;)
This is the same sort of idea as sessions... but with sessions nobody sees
their encrypted password (not that they can read it, its better for people
not to see the info at all if possible.. and better for search engines).
As someone else suggested, have a check on each page for a session variable
(which of course is set when they login).
<?
if (!isset($sessionvariable) {
header("Location:login.php");
exit;
}
?>
This can be in an include file, as a function (just remember to globalise
variables! I always forget :P), that way it will get checked on all your
protected pages :)
HTH
------------------------
Chris Smith
http://www.squiz.net
El Mar 13 Mar 2001 19:23, Christian Marschalek escribió: > Why not ask for a password, encrypt it (with 128bit or something;), check > it with the database (which has the encyrpted pwds) and pass the encrypted > password from page to page... > > like: <a href="blah.php?encryptedpassword"> Horrible idea!! Even with an encrypted password. Use PHP sessions, and save any info on the session (this is saved on a temp file on the server, and only the session handle is passed to the browser). -- System Administration: It's a dirty job, but someone told I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
> Horrible idea!! Even with an encrypted password. Use PHP > sessions, and save > any info on the session (this is saved on a temp file on the > server, and only > the session handle is passed to the browser). okido :) > System Administration: It's a dirty job, > but someone told I had to do it. i realy like that sentence :)
> As someone else suggested, have a check on each page for a
> session variable
> (which of course is set when they login).
>
> <?
> if (!isset($sessionvariable) {
> header("Location:login.php");
> exit;
> }
> ?>
will do.. what excatly are session variables?
> This can be in an include file, as a function (just remember to globalise
> variables! I always forget :P), that way it will get checked on all your
> protected pages :)
globalise? there are no global variables in php, are they?;)
regards
Hey,
> > As someone else suggested, have a check on each page for a
> > session variable
> > (which of course is set when they login).
> >
> > <?
> > if (!isset($sessionvariable) {
> > header("Location:login.php");
> > exit;
> > }
> > ?>
>
>will do.. what excatly are session variables?
check out http://www.php.net/manual/en/ref.session.php for session info..
> > This can be in an include file, as a function (just remember to globalise
> > variables! I always forget :P), that way it will get checked on all your
> > protected pages :)
>
>globalise? there are no global variables in php, are they?;)
With functions, you can either pass variables or reference variables
outside the function (for example, with a login function)... if they aren't
passed to the function & need to be referenced, they have to be a global
variable. Example below..
If you don't globalise the variable, then the form action will be nothing,
because the function doesn't know what it is or where to get it's value
from. Make sense?
function print_login_form () {
global $PHP_SELF;
?>
<form method="post" action="<? echo $PHP_SELF ?>">
Name
<input type="text" value="">
<br><br>
Password
<input type="password" value="">
<br><br>
<input type="submit" value="Log In">
</form>
<?
}
HTH
------------------------
Chris Smith
http://www.squiz.net
On Wed, Mar 14, 2001 at 02:39:28AM +0100, Christian Marschalek wrote:
> > Horrible idea!! Even with an encrypted password. Use PHP
> > sessions, and save
> > any info on the session (this is saved on a temp file on the
> > server, and only
> > the session handle is passed to the browser).
The HTTP protocol provides userid/password based authentication.
Using cookies or hidden variables in a form while a popular
approach is not the correct way to do this. Furthermore, a lot
of people out there surf through a junk filter which will
probably not let your cookie through. Mine certainly won't.
The solution is to use the HTTP auth stuff. You can do this
either using apache's Require dirrective at the server layer or
dirrectly in your scripts.
To do it using apache, you need to edit your httpd.conf or
appropriate configuration file and put in something like the
following:
<Dirrectory /foo>
AuthType Digest
AuthName "realm foo"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
</Dirrectory>
Or you could just put the stuff contained in the Dirrectory
stanza into a .htaccess file in the dirrectory you want to
restrict access too, however that is inefficient since the
.htaccess file needs to be stat'd ever time a page is accessed.
It also only allows dirrectory level granularity and it's a pain
in the ass to make the 401 message meaningfull. But it's
sufficient for many jobs and very fast. The apache approach also
supports the digest method giving some transportation security,
while the dirrect php approach does not.
To do it in your script, dirrectly you need to pay attention
to $PHP_AUTH_USER and $PHP_AUTH_PW. For example:
if(!isset($PHP_AUTH_USER)) {
Header("WWW-Authenticate: Basic realm=\"sis_access\"");
Header("HTTP/1.0 401 Unauthorized");
include ( 'denied.html' ); // or you could redirrect
exit;
}
Then test the password the same way. Passwords should (obviously)
be stored in an encrypted format (MD5 is suitable, or you can just
use good old DES crypt). This will provide you with localized
security. For transport level security you can either use the
digest method for authentication, or if you're really serious, an
SSL connection. Of course if you're _really_ serious you're going
to be using x509 cert's and public key crypto, not some rinky dink
password based system.
> > System Administration: It's a dirty job,
Then you're doing it wrong.
I use this solution too, in order to authenticate my users....
My users/password table is into a PostgreSQL database.
Cassio.
----- Original Message -----
From: "Andrew Hammond" <drew@waugh.econ.queensu.ca>
To: "[PHP] PostgreSQL" <pgsql-php@postgresql.org>
Sent: Thursday, March 15, 2001 7:37 AM
Subject: [PHP] the "correct" way to login.
> On Wed, Mar 14, 2001 at 02:39:28AM +0100, Christian Marschalek wrote:
> > > Horrible idea!! Even with an encrypted password. Use PHP
> > > sessions, and save
> > > any info on the session (this is saved on a temp file on the
> > > server, and only
> > > the session handle is passed to the browser).
>
> The HTTP protocol provides userid/password based authentication.
> Using cookies or hidden variables in a form while a popular
> approach is not the correct way to do this. Furthermore, a lot
> of people out there surf through a junk filter which will
> probably not let your cookie through. Mine certainly won't.
>
> The solution is to use the HTTP auth stuff. You can do this
> either using apache's Require dirrective at the server layer or
> dirrectly in your scripts.
>
> To do it using apache, you need to edit your httpd.conf or
> appropriate configuration file and put in something like the
> following:
>
> <Dirrectory /foo>
> AuthType Digest
> AuthName "realm foo"
> AuthUserFile /web/users
> AuthGroupFile /web/groups
> Require group admin
> </Dirrectory>
>
> Or you could just put the stuff contained in the Dirrectory
> stanza into a .htaccess file in the dirrectory you want to
> restrict access too, however that is inefficient since the
> .htaccess file needs to be stat'd ever time a page is accessed.
> It also only allows dirrectory level granularity and it's a pain
> in the ass to make the 401 message meaningfull. But it's
> sufficient for many jobs and very fast. The apache approach also
> supports the digest method giving some transportation security,
> while the dirrect php approach does not.
>
> To do it in your script, dirrectly you need to pay attention
> to $PHP_AUTH_USER and $PHP_AUTH_PW. For example:
>
> if(!isset($PHP_AUTH_USER)) {
> Header("WWW-Authenticate: Basic realm=\"sis_access\"");
> Header("HTTP/1.0 401 Unauthorized");
> include ( 'denied.html' ); // or you could redirrect
> exit;
> }
>
> Then test the password the same way. Passwords should (obviously)
> be stored in an encrypted format (MD5 is suitable, or you can just
> use good old DES crypt). This will provide you with localized
> security. For transport level security you can either use the
> digest method for authentication, or if you're really serious, an
> SSL connection. Of course if you're _really_ serious you're going
> to be using x509 cert's and public key crypto, not some rinky dink
> password based system.
>
> > > System Administration: It's a dirty job,
>
> Then you're doing it wrong.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
I've had problems with this solution. I had to switch phpPgAdmin from
HTTP-Auth to a standard HTML form because of problems running it on a
non-apache server.
Just an FYI.
-Dan
: I use this solution too, in order to authenticate my users....
:
: My users/password table is into a PostgreSQL database.
:
: Cassio.
: ----- Original Message -----
: From: "Andrew Hammond" <drew@waugh.econ.queensu.ca>
: To: "[PHP] PostgreSQL" <pgsql-php@postgresql.org>
: Sent: Thursday, March 15, 2001 7:37 AM
: Subject: [PHP] the "correct" way to login.
:
:
: > On Wed, Mar 14, 2001 at 02:39:28AM +0100, Christian Marschalek wrote:
: > > > Horrible idea!! Even with an encrypted password. Use PHP
: > > > sessions, and save
: > > > any info on the session (this is saved on a temp file on the
: > > > server, and only
: > > > the session handle is passed to the browser).
: >
: > The HTTP protocol provides userid/password based authentication.
: > Using cookies or hidden variables in a form while a popular
: > approach is not the correct way to do this. Furthermore, a lot
: > of people out there surf through a junk filter which will
: > probably not let your cookie through. Mine certainly won't.
: >
: > The solution is to use the HTTP auth stuff. You can do this
: > either using apache's Require dirrective at the server layer or
: > dirrectly in your scripts.
: >
: > To do it using apache, you need to edit your httpd.conf or
: > appropriate configuration file and put in something like the
: > following:
: >
: > <Dirrectory /foo>
: > AuthType Digest
: > AuthName "realm foo"
: > AuthUserFile /web/users
: > AuthGroupFile /web/groups
: > Require group admin
: > </Dirrectory>
: >
: > Or you could just put the stuff contained in the Dirrectory
: > stanza into a .htaccess file in the dirrectory you want to
: > restrict access too, however that is inefficient since the
: > .htaccess file needs to be stat'd ever time a page is accessed.
: > It also only allows dirrectory level granularity and it's a pain
: > in the ass to make the 401 message meaningfull. But it's
: > sufficient for many jobs and very fast. The apache approach also
: > supports the digest method giving some transportation security,
: > while the dirrect php approach does not.
: >
: > To do it in your script, dirrectly you need to pay attention
: > to $PHP_AUTH_USER and $PHP_AUTH_PW. For example:
: >
: > if(!isset($PHP_AUTH_USER)) {
: > Header("WWW-Authenticate: Basic realm=\"sis_access\"");
: > Header("HTTP/1.0 401 Unauthorized");
: > include ( 'denied.html' ); // or you could redirrect
: > exit;
: > }
: >
: > Then test the password the same way. Passwords should (obviously)
: > be stored in an encrypted format (MD5 is suitable, or you can just
: > use good old DES crypt). This will provide you with localized
: > security. For transport level security you can either use the
: > digest method for authentication, or if you're really serious, an
: > SSL connection. Of course if you're _really_ serious you're going
: > to be using x509 cert's and public key crypto, not some rinky dink
: > password based system.
: >
: > > > System Administration: It's a dirty job,
: >
: > Then you're doing it wrong.
: >
: > ---------------------------(end of broadcast)---------------------------
: > TIP 4: Don't 'kill -9' the postmaster
: >
:
:
: ---------------------------(end of broadcast)---------------------------
: TIP 5: Have you checked our extensive FAQ?
:
: http://www.postgresql.org/users-lounge/docs/faq.html
HTTP auth is bad for several reasons.
1) The user/pass is submitted upon each request to the page.
2) There is no way to control how long a session lasts (auto-logout after a
certain time)
3) There is no way to end the session explicitly (logout button)
4) There is built-in session support in PHP4. Use it. =)
When I build applications that require a login, I have each file include a
"common.inc" file that contains shared (global) variables and functions. It
also forces a login...
<?php
//
// common.inc
//
// set global variables
...
// initialize session (8hr auto-expire)
session_set_cookie_params(28800);
session_start();
session_register("ses_user");
session_register("ses_pass");
// $username and $password are passed via POST from a login form
if (isset($username))
$ses_user = $username;
if (isset($password))
$ses_pass = $password;
// allow for logout if $logout is set via GET or POST
if (isset($logout)) {
unset($ses_user);
unset($ses_pass);
session_destroy();
session_unset();
}
// if unauthorized, allow for login
if ( ($ses_user) && ($ses_pass) ) {
// check user/pass against database, .htaccess file, etc.
...
// if user/pass is valid,
define("USER_AUTHORIZED", 1);
}
if (!defined("USER_AUTHORIZED")) {
// redirect or print login form via include();
...
}
?>
----- Original Message -----
From: "Dan Wilson" <phpPgAdmin@acucore.com>
To: "[PHP] PostgreSQL" <pgsql-php@postgresql.org>
Sent: Thursday, March 15, 2001 10:31 AM
Subject: Re: [PHP] the "correct" way to login.
I've had problems with this solution. I had to switch phpPgAdmin from
HTTP-Auth to a standard HTML form because of problems running it on a
non-apache server.
Just an FYI.
-Dan
: I use this solution too, in order to authenticate my users....
:
: My users/password table is into a PostgreSQL database.
:
: Cassio.
: ----- Original Message -----
: From: "Andrew Hammond" <drew@waugh.econ.queensu.ca>
: To: "[PHP] PostgreSQL" <pgsql-php@postgresql.org>
: Sent: Thursday, March 15, 2001 7:37 AM
: Subject: [PHP] the "correct" way to login.
:
:
: > On Wed, Mar 14, 2001 at 02:39:28AM +0100, Christian Marschalek wrote:
: > > > Horrible idea!! Even with an encrypted password. Use PHP
: > > > sessions, and save
: > > > any info on the session (this is saved on a temp file on the
: > > > server, and only
: > > > the session handle is passed to the browser).
: >
: > The HTTP protocol provides userid/password based authentication.
: > Using cookies or hidden variables in a form while a popular
: > approach is not the correct way to do this. Furthermore, a lot
: > of people out there surf through a junk filter which will
: > probably not let your cookie through. Mine certainly won't.
: >
: > The solution is to use the HTTP auth stuff. You can do this
: > either using apache's Require dirrective at the server layer or
: > dirrectly in your scripts.
: >
: > To do it using apache, you need to edit your httpd.conf or
: > appropriate configuration file and put in something like the
: > following:
: >
: > <Dirrectory /foo>
: > AuthType Digest
: > AuthName "realm foo"
: > AuthUserFile /web/users
: > AuthGroupFile /web/groups
: > Require group admin
: > </Dirrectory>
: >
: > Or you could just put the stuff contained in the Dirrectory
: > stanza into a .htaccess file in the dirrectory you want to
: > restrict access too, however that is inefficient since the
: > .htaccess file needs to be stat'd ever time a page is accessed.
: > It also only allows dirrectory level granularity and it's a pain
: > in the ass to make the 401 message meaningfull. But it's
: > sufficient for many jobs and very fast. The apache approach also
: > supports the digest method giving some transportation security,
: > while the dirrect php approach does not.
: >
: > To do it in your script, dirrectly you need to pay attention
: > to $PHP_AUTH_USER and $PHP_AUTH_PW. For example:
: >
: > if(!isset($PHP_AUTH_USER)) {
: > Header("WWW-Authenticate: Basic realm=\"sis_access\"");
: > Header("HTTP/1.0 401 Unauthorized");
: > include ( 'denied.html' ); // or you could redirrect
: > exit;
: > }
: >
: > Then test the password the same way. Passwords should (obviously)
: > be stored in an encrypted format (MD5 is suitable, or you can just
: > use good old DES crypt). This will provide you with localized
: > security. For transport level security you can either use the
: > digest method for authentication, or if you're really serious, an
: > SSL connection. Of course if you're _really_ serious you're going
: > to be using x509 cert's and public key crypto, not some rinky dink
: > password based system.
: >
: > > > System Administration: It's a dirty job,
: >
: > Then you're doing it wrong.
: >
: > ---------------------------(end of broadcast)---------------------------
: > TIP 4: Don't 'kill -9' the postmaster
: >
:
:
: ---------------------------(end of broadcast)---------------------------
: TIP 5: Have you checked our extensive FAQ?
:
: http://www.postgresql.org/users-lounge/docs/faq.html
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
On Sat, Mar 17, 2001 at 01:58:15AM -0800, Jon Tai wrote: > HTTP auth is bad for several reasons. > > 1) The user/pass is submitted upon each request to the page. As it is with the cookie solution you provide below. Assuming you have one, what's your point? > 2) There is no way to control how long a session lasts (auto-logout after a > certain time) That is incorrect. Not only is this possible but it's relatively trivial. I know because I've done it. > 3) There is no way to end the session explicitly (logout button) IBID. And a much more severe problem is present with your form based login. You may be shocked to hear this, but some web browsers have a history feature which allows evil bad people to discover userid/password combinations in URL's accessed by GET forms. So of course you have to POST the form instead. The variables from POSTed forms are typically cached so you'd better not forget to expire the content. So you're good to go, except for that damned cookie file. While you can easily set a expiry date on a cookie, that doesn't necessarily purge it from the cookie file. In fact, some browsers only vacuum their cookie jar on startup / shutdown. And it doesn't take a whole lot of clue to dissect a cookie file. > 4) There is built-in session support in PHP4. Use it. =) There is built-in authorization support in the HTTP standard. Use it. Try reading "HTTP 1.1" RFC 2068 sections 10.4.2, 11 and 14.8. So, I say again: the correct way to solve this problem is to use HTTP authentication. Standards exist for a reason.
The easiest way in PHP that I have found is to create a file called
validate.php containing the following:
<?
if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
header("Location: http://my.company.com/login");
}
?>
and, after the user has logged in, set a cookie. Then, for each page that
should be for a logged-in user only, just include the validate.php file.
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Tue, 13 Mar 2001 Timothy_Maguire@hartehanks.com wrote:
>
> if you are using apache web server you can try the .htaccess method. I am
> not too familar with it. I am trying to learn it myself, but from what i
> gather, you put a file called .htaccess in the dir where your web page is.
> the .htaccess file contains a path to the a file where all the user names
> and passwords are stored. whenever this dir is accessed, a window pops up
> asking for a user id and password.
>
> If anyone has more info on this, please pass it on. I am looking into
> using this as well. What i am looking to do is create a web based ftp
> application. Where users log into a web screen and can ftp files to the
> server into a certain directory own by them. I am storing the file paths
> and descriptions in a postgresql db and using php for the ftp process. Can
> I use .htaccess with this? Can I have someone log into the web page using
> .htaccess and passing their user id and password into a cookie or variable
> so i will know who they are and they don't have to re-type this when they
> ftp the file.
>
> Any help would be great.
> Thanks,
> Tim.
>
>
>
>
> Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
> 12:20:57 PM
>
> Sent by: pgsql-php-owner@postgresql.org
>
>
> To: pgsql-php@postgresql.org
> cc:
>
> Subject: Secure pages
>
>
> Hi everybody,
> i have a user login authentication sysytem on my machine here where users
> may view pages but to do other things the user must login. the login
> scripts seem to work ok and are based on a "Secure Authentication System"
> from www.phpbuilder.com. Basically the page where i want people to arrive
> at upon logging in is at present viewable by anyone who puts the proper
> url into their browser. how do i keep this and other pages secure from
> people who havent logged in?
> Thanks,
> Paul
>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
On Tue, 13 Mar 2001, Michael Fork wrote: ->not if the include file ends with a .php -- since it is in <? ?>, anybody ->acessing the file from a web browser would not be able to see it. I misunderstood, I thought you meant that you would put that code in an included file. Which anybody could get at. However the code being hidden doesn't change that I could look for a cookie from your domain, see it's value, and still create another cookie. What you're all looking for is a *session based* authentication system. PHP does this, and you can do it yourself if you have a database set up. -- Dave ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
not if the include file ends with a .php -- since it is in <? ?>, anybody
acessing the file from a web browser would not be able to see it.
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Tue, 13 Mar 2001, David Olbersen wrote:
> On Tue, 13 Mar 2001, Michael Fork wrote:
>
> ->The easiest way in PHP that I have found is to create a file called
> ->validate.php containing the following:
> ->
> -><?
> -> if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
> -> header("Location: http://my.company.com/login");
> -> }
> ->?>
> ->
> ->and, after the user has logged in, set a cookie. Then, for each page that
> ->should be for a logged-in user only, just include the validate.php file.
>
> Boy that's not very secure...I could find your included file, see what 'Some
> Value' is, and then just make my own cookie!
>
> -- Dave
>
>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
if you are using apache web server you can try the .htaccess method. I am
not too familar with it. I am trying to learn it myself, but from what i
gather, you put a file called .htaccess in the dir where your web page is.
the .htaccess file contains a path to the a file where all the user names
and passwords are stored. whenever this dir is accessed, a window pops up
asking for a user id and password.
If anyone has more info on this, please pass it on. I am looking into
using this as well. What i am looking to do is create a web based ftp
application. Where users log into a web screen and can ftp files to the
server into a certain directory own by them. I am storing the file paths
and descriptions in a postgresql db and using php for the ftp process. Can
I use .htaccess with this? Can I have someone log into the web page using
.htaccess and passing their user id and password into a cookie or variable
so i will know who they are and they don't have to re-type this when they
ftp the file.
Any help would be great.
Thanks,
Tim.
Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
12:20:57 PM
Sent by: pgsql-php-owner@postgresql.org
To: pgsql-php@postgresql.org
cc:
Subject: Secure pages
Hi everybody,
i have a user login authentication sysytem on my machine here where users
may view pages but to do other things the user must login. the login
scripts seem to work ok and are based on a "Secure Authentication System"
from www.phpbuilder.com. Basically the page where i want people to arrive
at upon logging in is at present viewable by anyone who puts the proper
url into their browser. how do i keep this and other pages secure from
people who havent logged in?
Thanks,
Paul
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
On Tue, 13 Mar 2001, Michael Fork wrote:
->The easiest way in PHP that I have found is to create a file called
->validate.php containing the following:
->
-><?
-> if ($HTTP_COOKIE_VARS["MyCookie"] != 'Some Value') {
-> header("Location: http://my.company.com/login");
-> }
->?>
->
->and, after the user has logged in, set a cookie. Then, for each page that
->should be for a logged-in user only, just include the validate.php file.
Boy that's not very secure...I could find your included file, see what 'Some
Value' is, and then just make my own cookie!
-- Dave
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> Hi everybody, > i have a user login authentication sysytem on my machine here where users > may view pages but to do other things the user must login. the login > scripts seem to work ok and are based on a "Secure Authentication System" > from www.phpbuilder.com. Basically the page where i want people to arrive > at upon logging in is at present viewable by anyone who puts the proper > url into their browser. how do i keep this and other pages secure from > people who havent logged in? > Thanks, > Paul Create a session. If (!(isset($session))) then redirect to login.php or your authentication file. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
You can do it with a .htaccess file, but why? You've got a very powerful
scripting language to work with...
I do it through a normal html form. Here's how I do it:
1) My login form and logic is all contained within an include file. That way,
I can include it within any page I feel should be password protected and it
automatically does everything.
2) The form action is left blank so that it will simply reload the same page
and take them to the page (and QUERY_STRING [GET] variables) they originally
intended.
3) The form contains a hidden input tag that is the controling variable.
4) I have an if statement within the login.inc.php file that checks to see if
the control variable is set... if it is, I check the login information against
my authentication scheme (usually a database).
5) If the login info is correct, then set cookies indicating that it's good
and let the page load rather than displaying the login box again. If the
login is invalid, display unset your control variable and let the login screen
load again. Of course, you should also display some type of message indicating
that the login failed.
6) Next time they hit the page where the login.inc.php file is included, it
checks the cookies to see if they have already logged in... if so... let them
by without displaying the login screen.
7) Summary of logic:
a) Check to see if "logged in" cookie exists... if so, let them through
b) If cookie doesn't exist, check if control variable (passed from HTML form)
isset
c) If control variable set, check against database, otherwise display login
screen
d) If database check of login info is valid, let them through, otherwise
display login screen
This method is very reusable... because there is no action in the form tag and
all login is within the include file, all you do is include it within any
access controled file and it works seemlessly.
-Dan
: if you are using apache web server you can try the .htaccess method. I am
: not too familar with it. I am trying to learn it myself, but from what i
: gather, you put a file called .htaccess in the dir where your web page is.
: the .htaccess file contains a path to the a file where all the user names
: and passwords are stored. whenever this dir is accessed, a window pops up
: asking for a user id and password.
:
: If anyone has more info on this, please pass it on. I am looking into
: using this as well. What i am looking to do is create a web based ftp
: application. Where users log into a web screen and can ftp files to the
: server into a certain directory own by them. I am storing the file paths
: and descriptions in a postgresql db and using php for the ftp process. Can
: I use .htaccess with this? Can I have someone log into the web page using
: .htaccess and passing their user id and password into a cookie or variable
: so i will know who they are and they don't have to re-type this when they
: ftp the file.
:
: Any help would be great.
: Thanks,
: Tim.
:
:
:
:
: Paul Joseph McGee <mcgee@student.cs.ucc.ie>@postgresql.org on 03/13/2001
: 12:20:57 PM
:
: Sent by: pgsql-php-owner@postgresql.org
:
:
: To: pgsql-php@postgresql.org
: cc:
:
: Subject: Secure pages
:
:
: Hi everybody,
: i have a user login authentication sysytem on my machine here where users
: may view pages but to do other things the user must login. the login
: scripts seem to work ok and are based on a "Secure Authentication System"
: from www.phpbuilder.com. Basically the page where i want people to arrive
: at upon logging in is at present viewable by anyone who puts the proper
: url into their browser. how do i keep this and other pages secure from
: people who havent logged in?
: Thanks,
: Paul
:
: ---------------------------(end of broadcast)---------------------------
: TIP 2: you can get off all lists at once with the unregister command
: (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
:
:
:
:
:
: **********************************************************************
: This email and any files transmitted with it are confidential and
: intended solely for the use of the individual or entity to whom they
: are addressed. If you have received this email in error please notify
: the system manager.
:
: This footnote also confirms that this email message has been swept by
: MIMEsweeper for the presence of computer viruses.
:
: www.mimesweeper.com
: **********************************************************************
:
: ---------------------------(end of broadcast)---------------------------
: TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
what i have sone in the past for passwords on web pages is have something
like:
<?
if(md5($MyCookie) != "anencryptedpassword") {
header("Location:http//homepage.com/whatever");
}
that way even if someone got the file and wanted to find out what the "some
value" was it would be encrypted.
There are probably still ways around this, but for the info you are hiding
from people, this is probably safe enough, at least for me it is.
David Olbersen <dave@slickness.org>@postgresql.org on 03/13/2001 02:50:45
PM
Sent by: pgsql-php-owner@postgresql.org
To: Michael Fork <mfork@toledolink.com>
cc: <Timothy_Maguire@hartehanks.com>, Paul Joseph McGee
<mcgee@student.cs.ucc.ie>, <pgsql-php@postgresql.org>
Subject: Re: Re: Secure pages
On Tue, 13 Mar 2001, Michael Fork wrote:
->not if the include file ends with a .php -- since it is in <? ?>, anybody
->acessing the file from a web browser would not be able to see it.
I misunderstood, I thought you meant that you would put that code in an
included
file. Which anybody could get at. However the code being hidden doesn't
change
that I could look for a cookie from your domain, see it's value, and still
create another cookie.
What you're all looking for is a *session based* authentication system. PHP
does
this, and you can do it yourself if you have a database set up.
-- Dave
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
On Tue, 13 Mar 2001, Dan Wilson wrote: Is anyone else getting crap spewed at them from as far back as March on this list?
yip 123 messages today
-----Original Message-----
From: speedboy [mailto:speedboy@nomicrosoft.org]
Sent: Friday, November 16, 2001 9:42 AM
To: pgsql-php@postgresql.org
Subject: Re: [PHP] Re: Secure pages
On Tue, 13 Mar 2001, Dan Wilson wrote:
Is anyone else getting crap spewed at them from as far back as March on
this list?
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Fri, 16 Nov 2001, speedboy wrote: > On Tue, 13 Mar 2001, Dan Wilson wrote: > > Is anyone else getting crap spewed at them from as far back as March on > this list? yep Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
the offending user has been removed from the list ... On Fri, 16 Nov 2001, Vince Vielhaber wrote: > On Fri, 16 Nov 2001, speedboy wrote: > > > On Tue, 13 Mar 2001, Dan Wilson wrote: > > > > Is anyone else getting crap spewed at them from as far back as March on > > this list? > > yep > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
On Fri, 16 Nov 2001, Marc G. Fournier wrote: > > the offending user has been removed from the list ... I didn't look at the headers, you mean someone actually sent them and it wasn't a logjam somewhere? > > > On Fri, 16 Nov 2001, Vince Vielhaber wrote: > > > On Fri, 16 Nov 2001, speedboy wrote: > > > > > On Tue, 13 Mar 2001, Dan Wilson wrote: > > > > > > Is anyone else getting crap spewed at them from as far back as March on > > > this list? > > > > yep > > > > Vince. > > -- > > ========================================================================== > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > > Online Campground Directory http://www.camping-usa.com > > Online Giftshop Superstore http://www.cloudninegifts.com > > ========================================================================== > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
from what I could tell, yes ... might have been unintentioinal, but, if that's the case, they can re-subscribe :) On Fri, 16 Nov 2001, Vince Vielhaber wrote: > On Fri, 16 Nov 2001, Marc G. Fournier wrote: > > > > > the offending user has been removed from the list ... > > I didn't look at the headers, you mean someone actually sent them > and it wasn't a logjam somewhere? > > > > > > > On Fri, 16 Nov 2001, Vince Vielhaber wrote: > > > > > On Fri, 16 Nov 2001, speedboy wrote: > > > > > > > On Tue, 13 Mar 2001, Dan Wilson wrote: > > > > > > > > Is anyone else getting crap spewed at them from as far back as March on > > > > this list? > > > > > > yep > > > > > > Vince. > > > -- > > > ========================================================================== > > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > > > Online Campground Directory http://www.camping-usa.com > > > Online Giftshop Superstore http://www.cloudninegifts.com > > > ========================================================================== > > > > > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 2: you can get off all lists at once with the unregister command > > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > > > > > > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > >
This arrived promptly. :) On Fri, 16 Nov 2001, Marc G. Fournier wrote: > > from what I could tell, yes ... might have been unintentioinal, but, if > that's the case, they can re-subscribe :) > > > > On Fri, 16 Nov 2001, Vince Vielhaber wrote: > > > On Fri, 16 Nov 2001, Marc G. Fournier wrote: > > > > > > > > the offending user has been removed from the list ... > > > > I didn't look at the headers, you mean someone actually sent them > > and it wasn't a logjam somewhere? > > > > > > > > > > > On Fri, 16 Nov 2001, Vince Vielhaber wrote: > > > > > > > On Fri, 16 Nov 2001, speedboy wrote: > > > > > > > > > On Tue, 13 Mar 2001, Dan Wilson wrote: > > > > > > > > > > Is anyone else getting crap spewed at them from as far back as March on > > > > > this list? > > > > > > > > yep > > > > > > > > Vince. > > > > -- > > > > ========================================================================== > > > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > > > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > > > > Online Campground Directory http://www.camping-usa.com > > > > Online Giftshop Superstore http://www.cloudninegifts.com > > > > ========================================================================== > > > > > > > > > > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > > TIP 2: you can get off all lists at once with the unregister command > > > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > > > > > > > > > > > > > Vince. > > -- > > ========================================================================== > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > > Online Campground Directory http://www.camping-usa.com > > Online Giftshop Superstore http://www.cloudninegifts.com > > ========================================================================== > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================