phpesp-devel

[phpesp-dev] Proposed changes.

[Matthew G. <gr...@mu...>]

I've fielded several problems lately on #phpESP relating to the
mysql_populate.sql script.  It appears it is failing on mySQL vs 4 and
above.
The fix looks to be simply changing all:
NOT NULL DEFAULT '',
to:
NOT NULL,

See bug #: 890830

I want to commit these changes to CVS, any commments?

Also, I've had a feature request tagged to me for a while to implement
LDAP respondent accounts.  I have this implemented in a way that works
for us(MUSC), but it's done in a way that would allow for other
authentication methods to easily be used.  Instead of extending the
account/authentication functionality inside ESP, I choose to implement
the concept of a "valid URI" that a survey can be called from.  Then
from Apache you can use any authentication method it supports(which is
huge) to limit access to the Survey.

For example:
- The directory .../phpESP/public/access-ldap/ exists

- The valid URI for a survey is access-ldap

- Apache is configure as:
<Location /access-ldap/>
  AuthName "(LDAP ID and Password)"
  AuthType Basic
  AuthLDAP  "some ldap config here"
  require valid-user
</Location>

- The survey is activated.

- It is accessed by the normal "/public/survey.php?name=blah" url and
access is denied.

- It is accessed by the "secured" URL
"/public/access-ldap/survey.php?name=blah", a "Basic Auth" login is
prompted by Apache.  If the user has a valid account, they can access
the survey.

Do you guys like this approach?  Hope I managed to explain it well
enough.  If so, I'll clean it up and send out a patch that against CVS
for testing.  If not, I'll keep it as a local extension.  I'll take no
response as a "go a head and do it" (-:


-- 
mcg
--
The IT Lab (http://www.itlab.musc.edu)

Re: [phpesp-dev] Proposed changes.

[Christopher Z. <zo...@mu...>]

On Fri, Feb 06, 2004 at 04:49:14PM -0500, Matthew Gregg wrote:
> I've fielded several problems lately on #phpESP relating to the
> mysql_populate.sql script.  It appears it is failing on mySQL vs 4 and
> above.
> The fix looks to be simply changing all:
> NOT NULL DEFAULT '',
> to:
> NOT NULL,
> 
> See bug #: 890830
> 
> I want to commit these changes to CVS, any commments?

Nope. Looks fine. :) 

> 
> Also, I've had a feature request tagged to me for a while to implement
> LDAP respondent accounts.  I have this implemented in a way that works
> for us(MUSC), but it's done in a way that would allow for other
> authentication methods to easily be used.  Instead of extending the
> account/authentication functionality inside ESP, I choose to implement
> the concept of a "valid URI" that a survey can be called from.  Then
> from Apache you can use any authentication method it supports(which is
> huge) to limit access to the Survey.
> 
> For example:
> - The directory .../phpESP/public/access-ldap/ exists
> 
> - The valid URI for a survey is access-ldap
> 
> - Apache is configure as:
> <Location /access-ldap/>
>   AuthName "(LDAP ID and Password)"
>   AuthType Basic
>   AuthLDAP  "some ldap config here"
>   require valid-user
> </Location>
> 
> - The survey is activated.
> 
> - It is accessed by the normal "/public/survey.php?name=blah" url and
> access is denied.
> 
> - It is accessed by the "secured" URL
> "/public/access-ldap/survey.php?name=blah", a "Basic Auth" login is
> prompted by Apache.  If the user has a valid account, they can access
> the survey.
> 
> Do you guys like this approach?  Hope I managed to explain it well
> enough.  If so, I'll clean it up and send out a patch that against CVS
> for testing.  If not, I'll keep it as a local extension.  I'll take no
> response as a "go a head and do it" (-:
> 

I give it a +1 You should go ahead and do it. 

> 
> -- 
> mcg
> --
> The IT Lab (http://www.itlab.musc.edu)
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> 

Re: [phpesp-dev] Proposed changes.

[James E. F. <jf...@uv...>]

Matthew Gregg wrote:
> I've fielded several problems lately on #phpESP relating to the
> mysql_populate.sql script.  It appears it is failing on mySQL vs 4 and
> above.
> The fix looks to be simply changing all:
> NOT NULL DEFAULT '',
> to:
> NOT NULL,
> 
> See bug #: 890830
> 
> I want to commit these changes to CVS, any commments?

That sounds good.  The only thing I'm worried about is changing the 
behavior.  I think most "NOT NULL DEFAULT ''" clauses are used on 
timestamps, and by doing so causes MySQL3.x to set the field to the time 
the row was inserted.  I think it should be pretty easy to retain this 
behavior ... but I want to be sure it will DTRT on both MySQL 3 & 4.

> Also, I've had a feature request tagged to me for a while to implement
> LDAP respondent accounts.  I have this implemented in a way that works
> for us(MUSC), but it's done in a way that would allow for other
> authentication methods to easily be used.  Instead of extending the
> account/authentication functionality inside ESP, I choose to implement
> the concept of a "valid URI" that a survey can be called from.  Then
> from Apache you can use any authentication method it supports(which is
> huge) to limit access to the Survey.
> 
> For example:
> - The directory .../phpESP/public/access-ldap/ exists
> 
> - The valid URI for a survey is access-ldap
> 
> - Apache is configure as:
> <Location /access-ldap/>
>   AuthName "(LDAP ID and Password)"
>   AuthType Basic
>   AuthLDAP  "some ldap config here"
>   require valid-user
> </Location>
> 
> - The survey is activated.
> 
> - It is accessed by the normal "/public/survey.php?name=blah" url and
> access is denied.
> 
> - It is accessed by the "secured" URL
> "/public/access-ldap/survey.php?name=blah", a "Basic Auth" login is
> prompted by Apache.  If the user has a valid account, they can access
> the survey.
> 
> Do you guys like this approach?  Hope I managed to explain it well
> enough.  If so, I'll clean it up and send out a patch that against CVS
> for testing.  If not, I'll keep it as a local extension.  I'll take no
> response as a "go a head and do it" (-:

Well, the easiest way to do this would be to add a new auth module for 
phpESP, "auth_apache".  That way anyone using the phpesp user db won't 
have to migrate, but anyone who wants to can plug in any apache auth 
module and be ready to go.  I imagine the "auth_apache" plugin would be 
pretty simple (for respondents).

Perhaps the phpESP auth plugin stuff needs to be split into respondent / 
designer though.  So that something like auth_respondent=apache_auth, 
auth_designer=phpesp would be possible.  What do you think?

-James

Re: [phpesp-dev] Proposed changes.

[James E. F. <jf...@uv...>]

James E. Flemer wrote:
> Matthew Gregg wrote:
>
>> Also, I've had a feature request tagged to me for a while to implement
>> LDAP respondent accounts.  I have this implemented in a way that works
>> for us(MUSC), but it's done in a way that would allow for other
>> authentication methods to easily be used.  Instead of extending the
>> account/authentication functionality inside ESP, I choose to implement
>> the concept of a "valid URI" that a survey can be called from.  Then
>> from Apache you can use any authentication method it supports(which is
>> huge) to limit access to the Survey.
>>
>> For example:
>> - The directory .../phpESP/public/access-ldap/ exists
>>
>> - The valid URI for a survey is access-ldap
>>
>> - Apache is configure as:
>> <Location /access-ldap/>
>>   AuthName "(LDAP ID and Password)"
>>   AuthType Basic
>>   AuthLDAP  "some ldap config here"
>>   require valid-user
>> </Location>
>>
>> - The survey is activated.
>>
>> - It is accessed by the normal "/public/survey.php?name=blah" url and
>> access is denied.
>>
>> - It is accessed by the "secured" URL
>> "/public/access-ldap/survey.php?name=blah", a "Basic Auth" login is
>> prompted by Apache.  If the user has a valid account, they can access
>> the survey.
>>
>> Do you guys like this approach?  Hope I managed to explain it well
>> enough.  If so, I'll clean it up and send out a patch that against CVS
>> for testing.  If not, I'll keep it as a local extension.  I'll take no
>> response as a "go a head and do it" (-:
> 
> 
> Well, the easiest way to do this would be to add a new auth module for 
> phpESP, "auth_apache".  That way anyone using the phpesp user db won't 
> have to migrate, but anyone who wants to can plug in any apache auth 
> module and be ready to go.  I imagine the "auth_apache" plugin would be 
> pretty simple (for respondents).
> 
> Perhaps the phpESP auth plugin stuff needs to be split into respondent / 
> designer though.  So that something like auth_respondent=apache_auth, 
> auth_designer=phpesp would be possible.  What do you think?

Having thought about this a little more, I think phpESP needs a bit more 
of an AAA solution.  Well, maybe we can ignore the third "A" 
(accounting) for now, and just focus on authentication (authN) and 
authorization (authZ).  I think that we should try to use PEAR::Auth for 
authN possibly adding to that project to have an Apache pseudo-"storage 
container".  Then we need a simple but flexible authZ system.  Right now 
authN and authZ are all rolled up into one, which makes it difficult to 
leverage existing authN systems.  With separate "modules" one could 
easily get authn with ldap/apache/etc, but use (a subset of) the 
existing phpesp database for authz, or write a new authz module.

Or maybe we should make a PEAR::AuthZ module that is designed around 
PEAR::Auth.

Comments?

-James

Re: [phpesp-dev] Proposed changes.

[Matthew G. <gr...@mu...>]

On Sun, 2004-02-08 at 18:03, James E. Flemer wrote:
...snip...
> > 
> > 
> > Well, the easiest way to do this would be to add a new auth module for 
> > phpESP, "auth_apache".  That way anyone using the phpesp user db won't 
> > have to migrate, but anyone who wants to can plug in any apache auth 
> > module and be ready to go.  I imagine the "auth_apache" plugin would be 
> > pretty simple (for respondents).
> > 
> > Perhaps the phpESP auth plugin stuff needs to be split into respondent / 
> > designer though.  So that something like auth_respondent=apache_auth, 
> > auth_designer=phpesp would be possible.  What do you think?
> 
> Having thought about this a little more, I think phpESP needs a bit more 
> of an AAA solution.  Well, maybe we can ignore the third "A" 
> (accounting) for now, and just focus on authentication (authN) and 
> authorization (authZ).  I think that we should try to use PEAR::Auth for 
> authN possibly adding to that project to have an Apache pseudo-"storage 
> container".  Then we need a simple but flexible authZ system.  Right now 
> authN and authZ are all rolled up into one, which makes it difficult to 
> leverage existing authN systems.  With separate "modules" one could 
> easily get authn with ldap/apache/etc, but use (a subset of) the 
> existing phpesp database for authz, or write a new authz module.
> 
> Or maybe we should make a PEAR::AuthZ module that is designed around 
> PEAR::Auth.
> 
> Comments?
Erg.. you make stuff hard :-)
I'll read up on PEAR::Auth and think about this.


> 
> -James
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
-- 
mcg
-------------------------------------
The IT Lab (http://www.itlab.musc.edu)

Re: [phpesp-dev] Proposed changes.

[James E. F. <jf...@uv...>]

Matthew Gregg wrote:
> On Sun, 2004-02-08 at 18:03, James E. Flemer wrote:
--snip--
 >
>>Having thought about this a little more, I think phpESP needs a bit more 
>>of an AAA solution.  Well, maybe we can ignore the third "A" 
>>(accounting) for now, and just focus on authentication (authN) and 
>>authorization (authZ).  I think that we should try to use PEAR::Auth for 
>>authN possibly adding to that project to have an Apache pseudo-"storage 
>>container".  Then we need a simple but flexible authZ system.  Right now 
>>authN and authZ are all rolled up into one, which makes it difficult to 
>>leverage existing authN systems.  With separate "modules" one could 
>>easily get authn with ldap/apache/etc, but use (a subset of) the 
>>existing phpesp database for authz, or write a new authz module.
>>
>>Or maybe we should make a PEAR::AuthZ module that is designed around 
>>PEAR::Auth.
>>
>>Comments?
> 
> Erg.. you make stuff hard :-)
> I'll read up on PEAR::Auth and think about this.

Well, an interim solution could be just to implement an apache auth 
module for phpESP as I first mentioned.  I imagine that doing so would 
probably only take a few lines of code for respondents, and maybe a bit 
more for designers (unless you provide uniform authZ for all designers).

-James

Re: [phpesp-dev] Proposed changes.

[Matthew G. <gr...@mu...>]

On Sun, 2004-02-08 at 10:06, James E. Flemer wrote: 
> Matthew Gregg wrote:
> > I've fielded several problems lately on #phpESP relating to the
> > mysql_populate.sql script.  It appears it is failing on mySQL vs 4 and
> > above.
> > The fix looks to be simply changing all:
> > NOT NULL DEFAULT '',
> > to:
> > NOT NULL,
> > 
> > See bug #: 890830
> > 
> > I want to commit these changes to CVS, any commments?
> 
> That sounds good.  The only thing I'm worried about is changing the 
> behavior.  I think most "NOT NULL DEFAULT ''" clauses are used on 
> timestamps, and by doing so causes MySQL3.x to set the field to the time 
> the row was inserted.  I think it should be pretty easy to retain this 
> behavior ... but I want to be sure it will DTRT on both MySQL 3 & 4.
You are correct the problem is with the "changed" column of type
TIMESTAMP.  Other TIMESTAMP columns did not specify the "DEFAULT ''".

Documentation for mysql 3 and 4(when not running in MAXDB mode) appear
to have identical behavior:
--
Automatic updating of the first TIMESTAMP column occurs under any of the
following conditions:

The column is not specified explicitly in an INSERT or LOAD DATA INFILE
statement.

The column is not specified explicitly in an UPDATE statement and some
other column changes value. (Note that an UPDATE that sets a column to
the value it already has will not cause the TIMESTAMP column to be
updated, because if you set a column to its current value, MySQL ignores
the update for efficiency.)

You explicitly set the TIMESTAMP column to NULL.

If mysql 4 is running in MAXDB mode no auto updates to timestamp field
occur.
--

It appears mysql 4 just disallows the "DEFAULT ''", clause on TIMESTAMP
fields.  A grep of the ESP sources, reveals only two explicit references
to the "changed" column in "admdesigner.inc" and "admrespondent.inc" and
they specify "changed=now()".  So.. based on this and a mysql dump of
our ESP installation the corrected SQL should be:
changed TIMESTAMP(14) DEFAULT NULL,

instead of

changed TIMESTAMP(14) NOT NULL DEFAULT '',


Does anyone have access to mysql 3.x to test this?

...snip...



-- 
mcg
--
The IT Lab (http://www.itlab.musc.edu)