phplib-users — A list for users of phplib to talk / discuss phplib

[Phplib-users] Re: Default Auth? 7.2d

[Christian R. <ro...@in...>]

Hello Jacob, Fred and All!

> > So basically, if a user who is authenticated as "nobody" attempts to
> > access a protected page (which contains the following after
> > page_open)
> > =20
> > $auth->login_if($auth->auth["uid"] =3D=3D "nobody");
> >=20
> > ...authentication is destroyed and the user must login in order to do
> > *anything*.

I have the same problem here.

> If you set it up right, clicking the "Cancel" button on the login form
> will get you out of the modal login state and back to some accessible
> page. =20

My 7.2d didn't come with a login form with a "Cancel" button!
Unless I missed something?

> The login form/page acts much like a modal dialog box -- the
> visitor should exit it via one of the form's submit buttons.

Why should it?  I think it's perfectly normal for someone to access a
protected page and then hit "Home" link of the menu!  From a user point of
view, having to hit "cancel" on the login form to access the non-protected
pages is not natural.

> As you say, while in that login state with phplib, all pages using
> authentication (i.e., those that specify an "auth" class in the
> page_open call) will demand a login. =20

There must be something we can do to change that!

> But why do you want to allow the visitor to access
> other pages while in the midst of login?  If there is some "help" page
> that explains the login policy, perhaps you can avoid using an auth
> class at all with that page.

Here's why...

The home page will show different things depending if the user is logged
in or not.  For example, when the user is logged in, the menu of every
pages (including the home page which is public) show the "Register" link
when you are not logged in.  When you ARE logged in the "Register" link is
not there but it shows "Logged in as 'user123'."

So, the home page (and all public pages) must be able to determine if the
user is logged in.  One natural way (as per documentation) is to use
Default Auth.  Incomming users will be logged in as "nobody" until they
login!  When the user hit a protected page and decide to go back to the
home page, he should still be logged in as "nobody"!  He should not be
presented with a login form on the home page, ever!

Possible solutions I am thinking to investigate :

1) Hack PHPLIB and fix it!
2) Use $sess on all pages to help track if you are logged in or not!
3) change the '$auth->login_if($auth->auth["uid"] =3D=3D "nobody");'
   by 'if($auth->auth["uid"] =3D=3D "nobody") {
         include"loginform.php";
         page_close(); exit;
       }' on all pages which are protected.  The form will be displayed
   without having PHPLIB screw the "nobody" authentication.

I haven't tried any of those yet.  I will probably try #1 and submit by
changes here.

Good luck!

--=20

Christian Roy <cr...@in...>
Station InfiniWeb inc.
http://www.infiniweb.ca
/* H=E9bergement Web - Programmation Web - Sites Web - Nom de domaine  */
/* Web Hosting - Web Programming - Instant Websites - Domain name    */

Re: [Phplib-users] Default Auth? 7.2d

[<fr...@on...>]

On Thu, Feb 14, 2002 at 03:47:05PM -0700, Jacob Hanson wrote:
> It would seem that the "default authentication" setup is flawed because
> login_if destroys authentication. Once it's destroyed, there doesn't
> seem to way to get re-authenticated as "nobody".

If you set it up right, clicking the "Cancel" button on the login form
will get you out of the modal login state and back to some accessible
page.

The login form/page acts much like a modal dialog box -- the visitor
should exit it via one of the form's submit buttons.  As you say,
while in that login state with phplib, all pages using authentication
(i.e., those that specify an "auth" class in the page_open call) will
demand a login.

But why do you want to allow the visitor to access other pages while
in the midst of login?  If there is some "help" page that explains the
login policy, perhaps you can avoid using an auth class at all with
that page.

-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] Default Auth? 7.2d

[Jacob H. <Jac...@fi...>]

Ok, after more hacking (yes, I'm still at it)...
 
It would seem that the "default authentication" setup is flawed because
login_if destroys authentication. Once it's destroyed, there doesn't
seem to way to get re-authenticated as "nobody". On my system, this
forces the included loginform on every page that uses $auth, including
the ones that are otherwise accessible by "nobody", such as the nice,
external login form/title page I just created.

So basically, if a user who is authenticated as "nobody" attempts to
access a protected page (which contains the following after page_open)
 
$auth->login_if($auth->auth["uid"] == "nobody");

...authentication is destroyed and the user must login in order to do
*anything*.

The external login form I was talking about previously gets me around
part of the problem, but still, if a user somehow manages to browse to a
protected page, they get the simple included loginform and that's all
they'll be able to get until they can get a different session.
 
It seems like the only answer is to not use $auth at all on
non-protected pages, as Layne suggested. Although, I wish I could...
 
Jacob
 
>>> "Jacob Hanson" <Jac...@fi...> 02/14/02 12:41PM >>>

Ah! After further testing...
 
It seems as thought having "nobody"-accessible links on your included
loginform file can't work. I'm using Fred's method.
 
If I access the other files directly, it works fine, but going through
the links on the loginform, it doesn't. Browsing the "default" page
(home.php, which is protected, so the loginform will display for
unauthenticated users) it turns out that I am correctly authenticated as
"nobody" initially. But since I've got an if_login() hook in there to
only allow authenticated users into home.php, if_login() nukes my
"nobody" auth info, which breaks the public links on the loginform.
 
So it seems the only solution is to use welcome.php as an outside
loginform (which would POST its login info to the protected page) and as
the default page...and use a simple no-nonsense login form for the
included loginform.

Hmmm...
 



-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc        PGP keyID: 7B449345        fax: +1.630.879.1370
<A href="http://www.ontosys.com&nbsp;&nbsp;&nbsp;www.ontosys.com    
38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] Default Auth? 7.2d

[Jacob H. <Jac...@fi...>]

Ah! After further testing...
 
It seems as thought having "nobody"-accessible links on your included
loginform file can't work. I'm using Fred's method.
 
If I access the other files directly, it works fine, but going through
the links on the loginform, it doesn't. Browsing the "default" page
(home.php, which is protected, so the loginform will display for
unauthenticated users) it turns out that I am correctly authenticated as
"nobody" initially. But since I've got an if_login() hook in there to
only allow authenticated users into home.php, if_login() nukes my
"nobody" auth info, which breaks the public links on the loginform.
 
So it seems the only solution is to use welcome.php as an outside
loginform (which would POST its login info to the protected page) and as
the default page...and use a simple no-nonsense login form for the
included loginform.

Hmmm...
 

>>> <fr...@on...> 02/13/02 02:41PM >>>
On Wed, Feb 13, 2002 at 11:05:03AM -0700, Jacob Hanson wrote:
> The Default Auth feature seems like it should do the trick, but it's
> not working. I've set library.php to use my default_auth subclass,
but
> I'm still getting the login page when I try to access library.php.

It doesn't work to use different Auth subclasses on different pages of
the same website.  Whatever Auth subclass appears in the first
page_open() that the user visits will be the auth class for all pages
visited in the site while that session persists.

A common approach to allowing unrestricted access to some pages and
not others is to set up the application's Auth subclass to use
"default authentication" -- $auth->nobody == true -- and then force
login on restricted pages by using something like this right after
calling page_open():

    $auth->login_if($auth->auth["uid"] == "nobody");


-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc        PGP keyID: 7B449345        fax: +1.630.879.1370
<A href="http://www.ontosys.com&nbsp;&nbsp;&nbsp;www.ontosys.com    
38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] Default Auth? 7.2d

[Jacob H. <Jac...@fi...>]

Thanks for the responses to the default auth issue. I've got it now.
Perhaps the docs on default auth should be updated... The bit about
$sess using only the first $auth class that is used over the course of
it's life was an important clue for me.

>>> <fr...@on...> 02/13/02 02:41PM >>>
On Wed, Feb 13, 2002 at 11:05:03AM -0700, Jacob Hanson wrote:
> The Default Auth feature seems like it should do the trick, but it's
> not working. I've set library.php to use my default_auth subclass,
but
> I'm still getting the login page when I try to access library.php.

It doesn't work to use different Auth subclasses on different pages of
the same website.  Whatever Auth subclass appears in the first
page_open() that the user visits will be the auth class for all pages
visited in the site while that session persists.

A common approach to allowing unrestricted access to some pages and
not others is to set up the application's Auth subclass to use
"default authentication" -- $auth->nobody == true -- and then force
login on restricted pages by using something like this right after
calling page_open():

    $auth->login_if($auth->auth["uid"] == "nobody");


-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc        PGP keyID: 7B449345        fax: +1.630.879.1370
<A href="http://www.ontosys.com&nbsp;&nbsp;&nbsp;www.ontosys.com    
38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] Basic authentication

[Layne W. <la...@if...>]

> I can ASSUME that if I get a value username and password, I
> can give them access, IF this scheme prevents anyone from
> eavesdropping and gathering username/password pairs. If Bravo
> or a Bravo customer screws up and lets an unauthorized person
> have access to a username/password (e.g. by leaving themselves
> logged in, or other means), then it's not my or Acme's
> problem. As far as we know, the user is authorized.


The SSL encryption is, IIRC, setup before the actual request headers are
sent so your login info, whether in a posted form or in get vars as was also
suggested, will be sent securely. Just as the earlier posts activated my
paranoia mode (most things do these days), I would distrust my recollection
and test with a packet sniffer first.


> I'm still trying to poke holes in this because it seems too
> simple.


It seems like this solution meets your requirements, so I think you're safe.
(Nice reflexes, though.)


Layne Weathers
Ifworld Inc.

Re: [Phplib-users] Basic authentication

[Chris J. <ch...@ch...>]

Maybe what I'm doing is not clear enough.  I work for the Acme Company.  We
have an SSL-encrypted website that uses PHPLIB Auth authentication to
provide some services to our clients.

The Bravo Company also has an SSL-encrypted website for their customers.
Many of the Bravo customers might want to use the Acme services.  So my
company, Acme, has struck a business deal with Bravo, to provide access to
our services.  However, Bravo wants their users to only have to login
once -- that is log into the Bravo website.  Somewhere inside the Bravo
website, they want to put a link to our (Acme) website.  They want their
users to be able to click on that link and end up in our website, without
first having to type a username and password as our current customers do.

That is, Bravo customers are "pre-authorized" by virtue of coming from Bravo
and having signed in there first.  We, at Acme, will of course have a list
of those usernames and passwords from Bravo for the Bravo customers who want
to access Acme.

I'm looking for a way to securely identify them.  I can think of all kinds
of complicated ways to do it.  But it seems like a simple SSL form might be
all that's needed.  That is to say, on the Bravo web page, Bravo simply adds
a link like this:

<FORM METHOD=post ACTION="https://securesite.acme.com/bravopreauth.php" >
  <INPUT TYPE="hidden" NAME="username" value="BRAVO-USERNAME">
  <INPUT TYPE="hidden" NAME="password" value="BRAVO-PASSWORD">

  <INPUT TYPE=submit VALUE="Enter Acme">
</FORM>

This has many advantages, _IF_ it is secure enough.
1) Minimal programming on my part for the Acme Pre-Auth.
2) VERY minimal HTML changes on the part of Bravo for the Post FORM.
3) Bravo does not use PHP.  Bravo may, in fact, have next to no technical
resources to do this work, thus the easier for them, the better.  One-time
tokens for encryption, as suggested later by Layne Weathers might just break
the "tech effort" bank.

I'm not worried about future applications NOT using SSL.  Everything we do
is encrypted (it's health care data).

I can ASSUME that if I get a value username and password, I can give them
access, IF this scheme prevents anyone from eavesdropping and gathering
username/password pairs.  If Bravo or a Bravo customer screws up and lets an
unauthorized person have access to a username/password (e.g. by leaving
themselves logged in, or other means), then it's not my or Acme's problem.
As far as we know, the user is authorized.

I'm still trying to poke holes in this because it seems too simple.  But on
the other hand, it appears all data is being sent SSL-encrypted, so it is as
safe as SSL, which should be good enough for this application.  (we don't
make nuclear bombs  :-)

Make sense?

..chris


----- Original Message -----
From: "Peter Kursawe" <su...@si...>
To: <php...@li...>
Sent: Wednesday, February 13, 2002 2:38 AM
Subject: Re: [Phplib-users] Basic authentication


Hello Chris,

> They have proposed that they create a form on their page such that when
the
> submit button is clicked, they will POST the data to me and pass the
> username and password.

I don't understand how they will do that. Do you/they mean it like that:

1. user gets a loginform and enters username and password, press submit
("validate me!").

2. the login server must process the login

3. the login server validates login and shows a new form to the user with
his/her username and password in hidden fields and
a new submit button ("go to the application!")

4. user presses the submit button and comes to your server

This is possible to implement. And it is secure as long as you trust in the
users. Because in this setting the user can fake
the login server in building a form like that in 3. without having logged in
really.

Or --- do you/they mean like that:

1. and 2. (as above)

3. login server validates login and sends username and password directly to
your server via POST????

I don't know how to perform that. It may be possible, but I don't know how.

Peter Kursawe

_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Default Auth? 7.2d

[<fr...@on...>]

On Wed, Feb 13, 2002 at 11:05:03AM -0700, Jacob Hanson wrote:
> The Default Auth feature seems like it should do the trick, but it's
> not working. I've set library.php to use my default_auth subclass, but
> I'm still getting the login page when I try to access library.php.

It doesn't work to use different Auth subclasses on different pages of
the same website.  Whatever Auth subclass appears in the first
page_open() that the user visits will be the auth class for all pages
visited in the site while that session persists.

A common approach to allowing unrestricted access to some pages and
not others is to set up the application's Auth subclass to use
"default authentication" -- $auth->nobody == true -- and then force
login on restricted pages by using something like this right after
calling page_open():

	$auth->login_if($auth->auth["uid"] == "nobody");


-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] print fields after executing a query

[Lindsay H. <fm...@fm...>]

Thus spake Marco Müller on Tue, Feb 12, 2002 at 05:40:13PM CST
> 
> I thought that the pointer _is_ on the first row in the result after 
> executing the query. It's also nice for me to know that I can do a loop 
> with this. Fine!!!

Actually not.  It's not quite the same in php's database support, but many
db APIs and UIs support the concept of a BOF - "Beginning Of File"
pseudo-record, just as they support an EOF - "End Of File" pseudo-record. 
if you decrement the record pointer when you're on the first record or
increment it when you're on the last record you're positioned on one of
these, respecively - a condition that can be tested with something like "if
(BOF)" or "if (EOF)", and you may or may not be able to access real data in
such a case.  In phplib it's not quite the same, but similarly, you have to
explicitly position to a real record in a query result before you can get
real data out of it.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

Re: [Phplib-users] Default Auth? 7.2d

[Layne W. <la...@if...>]

> Now, I show a footer on all pages (including welcome.php) that
> has copyright info with links to a few things such as a Terms of
> Use document. All documents and articles on the site are viewed
> through library.php (which parses the articles into a template).
> Library.php uses my normal auth class and works fine, as long as
> the user is logged in, which is what I want...most of the time.
>
> However, I need to be able to grant access to Terms of Use, etc.
> to users who haven't logged in (such as viewing the document
> from welcome.php).


I don't even bother with default auth in these cases. In library.php I would
do this:

	if("/terms_of_use.php" == $HTTP_SERVER_VARS["SCRIPT_NAME"]) {
		page_open(array("sess" => "My_Session"));
	}
	else {
		page_open(array("sess" => "My_Session", "auth" => "My_Auth"));
	}


Layne Weathers
Ifworld Inc.

RE: [Phplib-users] Basic authentication

[Brian P. <bp...@ct...>]

>>This would not be secure at all for a non-SSL environment 
>>and I would prefer a better method even for an SSL environment
>>(cacheing, etc). If I can see the md5 of the password and token,
>>I don't need to see any more.

That's very true.. very true indeed. Although, keeping x tables of tokens
populated on two or more servers seems like a pretty daunting task. I
supposed you could have the tables on both sides automatically regenerate as
they are exhausted using some predetermined algorithm. I guess this is a
much more complicated problem than I originally surmised. Anyone else have
any ideas?

-BPopp 

-----Original Message-----
From: Layne Weathers [mailto:la...@if...]
Sent: Wednesday, February 13, 2002 11:43 AM
To: 'Phplib (E-mail)'
Subject: Re: [Phplib-users] Basic authentication


> I would go ahead and have them encrypt the username and
> password somehow before posting it. SSL should protect
> it from being intercepted, but you never know when you
> might want to use this same signon process somewhere
> else, in a non SSL environment. If you go ahead and expect
> encrypted data, you won't have to have two separate check's
> in your preauth, one for encrypted, one for not. An MD5 of
> the password and an agreed upon token would probably be
> adequate. This is purely hypothetical, but something
> similar should work I think (?) :
>
> Remote partner generates:
>
> $password = url_encode ( md5 ( $password . "magicword" ) );


This would not be secure at all for a non-SSL environment and I would prefer
a better method even for an SSL environment (cacheing, etc). If I can see
the md5 of the password and token, I don't need to see any more. This is the
problem that the Challenge Response Crypt extension of Auth was designed to
solve by ensuring a unique token with each login attempt. With a two-server
system, I would want to set up a library of tokens that both servers know
about, sort of like a spy's code book.

I would probably start with a list of at least a few million unique random
tokens. Each user should only be allowed to use each token once, otherwise
we're back to the problem above. The remote server would pull a token from
the list and send the offset to that token along with the encrypted
password. Your server would double check the offset against the user to
ensure that this attempt was unique and then check the login for validity.

However, we also need to prevent the remote server from using up tokens that
are never used - I'm sure that the users will not click to your site every
time they see a link on the remote site. To solve this, the remote server
links to a local (on the remote server) script. This script (acting much
like a click-through counter), finds a token, records it, encrypts the
password and redirects to your site.

E.g.:
	$offset = get_unique_offset( $user_id );
	$password = tokenize_user_password( $user_id, get_token( $offset )
);
	header("Location:
http://your_server/?username=$username&password=$password&offset=$offset");
	exit;


Layne Weathers
Ifworld Inc.


_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] Default Auth? 7.2d

[Jacob H. <Jac...@fi...>]

Hi list,
 
I've got a auth system based heavily on the examples in the docs.
 
A little background:
home.php: the "index page" for an authenticated user
welcome.php: my login form (replacing loginform.ihtml)
 
Basically, you go to the site and are taken to home.php. You're not
authenticated yet, so you see welcome.php. You can then log in and
access the rest of the site. This works great.
 
Now, I show a footer on all pages (including welcome.php) that has
copyright info with links to a few things such as a Terms of Use
document. All documents and articles on the site are viewed through
library.php (which parses the articles into a template). Library.php
uses my normal auth class and works fine, as long as the user is logged
in, which is what I want...most of the time.
 
However, I need to be able to grant access to Terms of Use, etc. to
users who haven't logged in (such as viewing the document from
welcome.php).
 
The Default Auth feature seems like it should do the trick, but it's
not working. I've set library.php to use my default_auth subclass, but
I'm still getting the login page when I try to access library.php.
 
My default_auth subclass is just like the one in the docs.
 
Any ideas?
 
Thanks,
 
Jacob

Re: [Phplib-users] Basic authentication

[Layne W. <la...@if...>]

> I would go ahead and have them encrypt the username and
> password somehow before posting it. SSL should protect
> it from being intercepted, but you never know when you
> might want to use this same signon process somewhere
> else, in a non SSL environment. If you go ahead and expect
> encrypted data, you won't have to have two separate check's
> in your preauth, one for encrypted, one for not. An MD5 of
> the password and an agreed upon token would probably be
> adequate. This is purely hypothetical, but something
> similar should work I think (?) :
>
> Remote partner generates:
>
> $password = url_encode ( md5 ( $password . "magicword" ) );


This would not be secure at all for a non-SSL environment and I would prefer
a better method even for an SSL environment (cacheing, etc). If I can see
the md5 of the password and token, I don't need to see any more. This is the
problem that the Challenge Response Crypt extension of Auth was designed to
solve by ensuring a unique token with each login attempt. With a two-server
system, I would want to set up a library of tokens that both servers know
about, sort of like a spy's code book.

I would probably start with a list of at least a few million unique random
tokens. Each user should only be allowed to use each token once, otherwise
we're back to the problem above. The remote server would pull a token from
the list and send the offset to that token along with the encrypted
password. Your server would double check the offset against the user to
ensure that this attempt was unique and then check the login for validity.

However, we also need to prevent the remote server from using up tokens that
are never used - I'm sure that the users will not click to your site every
time they see a link on the remote site. To solve this, the remote server
links to a local (on the remote server) script. This script (acting much
like a click-through counter), finds a token, records it, encrypts the
password and redirects to your site.

E.g.:
	$offset = get_unique_offset( $user_id );
	$password = tokenize_user_password( $user_id, get_token( $offset ) );
	header("Location:
http://your_server/?username=$username&password=$password&offset=$offset");
	exit;


Layne Weathers
Ifworld Inc.

RE: [Phplib-users] Basic authentication

[Brian P. <bp...@ct...>]

I would go ahead and have them encrypt the username and password somehow
before posting it. SSL should protect it from being intercepted, but you
never know when you might want to use this same signon process somewhere
else, in a non SSL environment. If you go ahead and expect encrypted data,
you won't have to have two separate check's in your preauth, one for
encrypted, one for not. An MD5 of the password and an agreed upon token
would probably be adequate. This is purely hypothetical, but something
similar should work I think (?) :

Remote partner generates:

$password = url_encode ( md5 ( $password . "magicword" ) );

and then links to:
"http://www.yourphplibsite.com?username=$username&pw=$password"


Then in YOUR auth_preauth() you'd have something like:

global $username, $pw;

$sql  = "SELECT * FROM auth_user WHERE username='$username'";

$db->query ( $sql );
if ( $db->next_record() )
{

	$dbuid = $db->f ( "user_id" );
	$dbpassword = $db->f ( "password" );

	$pw = url_decode ( $pw );

	if ( $pw == md5 ( $dbpassword . "magicword" ) )
	{
		return $dbuid;
	}
}
return 0;


-----Original Message-----
From: Chris Johnson [mailto:ch...@ch...]
Sent: Tuesday, February 12, 2002 8:44 PM
To: php...@li...
Subject: Re: [Phplib-users] Basic authentication


So, revisiting this issue a bit further:

If my "single signon" business partner who wants to send their users to my
secure site running PHPLIB without forcing their users to log in again did
the following, would that be sufficient?

They have proposed that they create a form on their page such that when the
submit button is clicked, they will POST the data to me and pass the
username and password.

Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be
secure.  I should then just be able to do an automated, behind the scenes
login using their name and password, right?

It seems too simple!  I'm always sceptical when it seems that easy.

Anyone see any flaws in this?

Thanks,
..chris


_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] oohforms textarea validation patch (fwd)

[Tarique S. <ta...@sa...>]

Hi this did not make it to the list

Tarique

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================
---------- Forwarded message ----------
Date: Wed, 13 Feb 2002 18:25:05 +0530 (IST)
From: "Tarique Sani <ta...@sa...>" <ro...@bo...>
To: Matt Williams <ma...@ye...>
Subject: oohforms textarea validation patch

Hi All,

The following is a JavaScript  minlength test for textarea - someone with
more time can elaborate it for rest of the stuff and also the serverside
stuff 

put these lines  in of_textarea.inc at the proper place

=====================================
function self_get_js($ndx_array) {
    $str = "";

    reset($ndx_array);
    while (list($k,$n) = each($ndx_array)) {
      if ($this->length_e) {
        $str .= "if (f.elements[${n}].value.length <
$this->minlength) {\n";
        $str .= "  alert(\"$this->length_e\");\n";
        $str .= "  f.elements[${n}].focus();\n";
        $str .= "  return(false);\n}\n";
      }
    }

    return $str;
  }
===================================

Hope that helps

Tarique


-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

RE: [Phplib-users] oohforms select validation

[Matt W. <ma...@ye...>]

> > Now I find myself at a loss about select box validation.
>
> I am not sure I get you - you just need that the user *must* select a
> value right?
>
> OR am I missing something?

I managed to sort it out. The manual says that the first option will not be
accepted by the validator.

But if the value of the first item is an integer and the values for the
other select items are strings, the validation will always fail.
Setting it to a string or leaving out the value attribute, will make the
validation behave as expected.

So if I have

"options"=>array(array("label"=>"Please Select","value"=>1),
			array("label"=>"Apple","value"=>"apple")),
"size"=>1,
"valid_e"=>"Please Select",

etc...

The validation will always fail.
But if I change the first option to
array("label"=>"Please Select")

The select box will validate as expected

m:

Re: [Phplib-users] oohforms select validation

[Tarique S. <ta...@sa...>]

On Wed, 13 Feb 2002, Matt Williams wrote:

> I got over the fact that I have to validate text boxes myself :(.

Not really, We just created a patch to validate textarea using min_length
and max_length attributes - no valid_e as yet BUT it is simple to do

Will post a patch soon
 
> Now I find myself at a loss about select box validation.

I am not sure I get you - you just need that the user *must* select a
value right? 

OR am I missing something?

Tarique

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

[Phplib-users] oohforms select validation

[Matt W. <ma...@ye...>]

Hi all

I'm really tring my best to get to grips with oohforms but I am having some
problems.

I got over the fact that I have to validate text boxes myself :(.

Now I find myself at a loss about select box validation.

I make the value of the select items integers. The validation performs
flawlessly.
However If make the first item 0 (which is used to test for a valid entry
and the other values the string values that I want. The select box always
fails validation no matter which option I select.

Is there anything else I have to do to make this work? Or does anyone have a
patch fix to get this working.

m:

Re: [Phplib-users] Basic authentication

[Peter K. <su...@si...>]

Hello Chris,

> They have proposed that they create a form on their page such that when the
> submit button is clicked, they will POST the data to me and pass the
> username and password.

I don't understand how they will do that. Do you/they mean it like that:

1. user gets a loginform and enters username and password, press submit ("validate me!").

2. the login server must process the login

3. the login server validates login and shows a new form to the user with his/her username and password in hidden fields and 
a new submit button ("go to the application!")

4. user presses the submit button and comes to your server

This is possible to implement. And it is secure as long as you trust in the users. Because in this setting the user can fake 
the login server in building a form like that in 3. without having logged in really.

Or --- do you/they mean like that:

1. and 2. (as above)

3. login server validates login and sends username and password directly to your server via POST????

I don't know how to perform that. It may be possible, but I don't know how.

Peter Kursawe

Re: [Phplib-users] Basic authentication

[Justin W. <jw...@sa...>]

Today @ 8:44pm, Chris Johnson typed..

> So, revisiting this issue a bit further:
>
> If my "single signon" business partner who wants to send their users to my
> secure site running PHPLIB without forcing their users to log in again did
> the following, would that be sufficient?
>
> They have proposed that they create a form on their page such that when the
> submit button is clicked, they will POST the data to me and pass the
> username and password.
>
> Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be
> secure.  I should then just be able to do an automated, behind the scenes
> login using their name and password, right?
>
> It seems too simple!  I'm always sceptical when it seems that easy.

One somewhat undesirable practice is to put the password plaintext in the
webpage.  Granted, it's SSL so only that person should see it, but even
so, most web services never ever let the user see their own password.  You
never know what could happen to your cached pages, or who may have
temporary access to your browser.

Isn't there an MD5 alternative?  or maybe you're already doing that and
that's what you're talking about.

Justin



>
> Anyone see any flaws in this?
>
> Thanks,
> ..chris
>
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>


_______________________________________________________
                               2 common misconceptions
       0) Pain is bad.
       1) Omniscience necessitates predestination.

Re: [Phplib-users] Basic authentication

[Tarique S. <ta...@sa...>]

On Tue, 12 Feb 2002, Chris Johnson wrote:

> secure.  I should then just be able to do an automated, behind the scenes
> login using their name and password, right?

Yes - you can use preauth() for this
 
> It seems too simple!  I'm always sceptical when it seems that easy.

Yes I guess so BUT I would like to hear from more people

Cause I am also going to do something similar soon (as in 'today' ;-)

Tarique

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

Re: [Phplib-users] Basic authentication

[Chris J. <ch...@ch...>]

So, revisiting this issue a bit further:

If my "single signon" business partner who wants to send their users to my
secure site running PHPLIB without forcing their users to log in again did
the following, would that be sufficient?

They have proposed that they create a form on their page such that when the
submit button is clicked, they will POST the data to me and pass the
username and password.

Since both sites are SSL (HTTPS) encrypted, the POST'ed data should be
secure.  I should then just be able to do an automated, behind the scenes
login using their name and password, right?

It seems too simple!  I'm always sceptical when it seems that easy.

Anyone see any flaws in this?

Thanks,
..chris

Re: [Phplib-users] print fields after executing a query

[Marco <new...@dk...>]

Thanks Lindsay. That's what I've read in the manual 5 minutes before. 
:-) But thank's for information.

I thought that the pointer _is_ on the first row in the result after 
executing the query. It's also nice for me to know that I can do a loop 
with this. Fine!!!

Thanks!
Marco


Lindsay Haisley wrote:

>next_record() is a standard method call of the database object in phplib,
>and many database management APIs have a similar function.  Retrieving data
>from a database is often a two step process.  Part 1 is the query, and part
>2 is positioning the record pointer in the query results.  You always have
>to call next_record() or some other function which actually positions the
>record pointer in order to retrieve actual db data.  next_record() returns a
>null value when you reach the end of the query results, so you can do things
>like
>
>while ($db->next_record()) {
>  ..... do something with the data
>}
>
>The loop will execute once for every record (row) in the query results.
>
>Thus spake Marco Müller on Tue, Feb 12, 2002 at 03:39:50PM CST
>
>>Hi Tarique, hi list,
>>
>>that was a real cool hint! ;-) Works fine for me now. But I think I've 
>>to look in the manual to "understand" the hint. ;-)
>>
>>Thanks
>>Marco
>>
>>
>>Tarique Sani < @sanisoft.com=""> wrote:
>>
>>>On Tue, 12 Feb 2002, Marco [ISO-8859-1] Mler wrote:
>>>
>>>>The problem is: I've checked the fieldnames but - nothing is returned 
>>>>with the command.
>>>>
>>>doing
>>>
>>>$db->next_record()
>>>
>>>before you try anything should help 
>>>
>>>
>>>Tarique
>>>
>>
>>
>>_______________________________________________
>>Phplib-users mailing list
>>Php...@li...
>>https://lists.sourceforge.net/lists/listinfo/phplib-users
>>
>

Re: [Phplib-users] print fields after executing a query

[Lindsay H. <fm...@fm...>]

next_record() is a standard method call of the database object in phplib,
and many database management APIs have a similar function.  Retrieving data
from a database is often a two step process.  Part 1 is the query, and part
2 is positioning the record pointer in the query results.  You always have
to call next_record() or some other function which actually positions the
record pointer in order to retrieve actual db data.  next_record() returns a
null value when you reach the end of the query results, so you can do things
like

while ($db->next_record()) {
  ..... do something with the data
}

The loop will execute once for every record (row) in the query results.

Thus spake Marco Müller on Tue, Feb 12, 2002 at 03:39:50PM CST
> Hi Tarique, hi list,
> 
> that was a real cool hint! ;-) Works fine for me now. But I think I've 
> to look in the manual to "understand" the hint. ;-)
> 
> Thanks
> Marco
> 
> 
> Tarique Sani < @sanisoft.com=""> wrote:
> 
> >On Tue, 12 Feb 2002, Marco [ISO-8859-1] Mler wrote:
> >
> >>The problem is: I've checked the fieldnames but - nothing is returned 
> >>with the command.
> >>
> >doing
> >
> >$db->next_record()
> >
> >before you try anything should help 
> >
> >
> >Tarique
> >
> 
> 
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

Re: [Phplib-users] print fields after executing a query

[Marco <new...@dk...>]

Hi Tarique, hi list,

that was a real cool hint! ;-) Works fine for me now. But I think I've 
to look in the manual to "understand" the hint. ;-)

Thanks
Marco


Tarique Sani < @sanisoft.com=""> wrote:

>On Tue, 12 Feb 2002, Marco [ISO-8859-1] Mler wrote:
>
>>The problem is: I've checked the fieldnames but - nothing is returned 
>>with the command.
>>
>doing
>
>$db->next_record()
>
>before you try anything should help 
>
>
>Tarique
>