phpesp-devel

[phpesp-dev] preliminary patch: respondent landing page

[Bishop B. <ph...@id...>]

All,

Attached is a preliminary patch to support a "landing page" for =20
respondents.  Here's how it works:  If use_landing =3D true in =20
configuration, then public/landing.php opens up.  That pages shows a =20
login box and any public surveys available in the system.

A respondent enters their username and password, and if valid, goes to =20
the landing page.  The landing page has three sections.  The first =20
section lists the surveys the respondent can currently complete (based =20
on the same availability logic found elsewhere in the app).  The =20
second section lists the surveys the respondent has had access to, but =20
does no longer.  For example, surveys that have moved to "done" =20
status.  The third section are "tools", where the respondent can =20
change their password, change their profile, get help, or log out.

I am not quite done with this.  I need to test a little more, =20
especially the LDAP part.  If anyone already has an LDAP environment =20
configured, I'd appreciate a test of this against your server.  I also =20
need to fill out the help pages.  Any review you can provide would be =20
appreciated.

I hope to have this patch finished in the next 24 hours.

Based on how the system is set up, there is one caveat to using the =20
landing page: <username,password> tuples must be unique throughout the =20
system.  Currently, the database says <username,realm> is unique, so =20
when entering a <username,password>, it's possible that the same =20
username in two different realms has the same password, in which case, =20
it's impossible to tell which user is which.  Right now, if the system =20
detects that case, the user is not allowed to log in.


Thoughts?

bishop

--=20
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] preliminary patch: respondent landing page

[Matthew G. <mat...@gm...>]

Sounds good except for username,password uniqueness.  Currently the way
users are assigned to multiple realms is that they will have 2 entries
with the same userid/password different realms(yes that is ugly, don't
blame me for that :-)).

Why not require that all the surveys on the landing page be in the same
realm as the user logging in?

Does this patch build on the previous patches you've sent?  I hope to
have time tomorrow to work on reviewing them.

On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
> All,
> 
> Attached is a preliminary patch to support a "landing page" for  
> respondents.  Here's how it works:  If use_landing = true in  
> configuration, then public/landing.php opens up.  That pages shows a  
> login box and any public surveys available in the system.
> 
> A respondent enters their username and password, and if valid, goes to  
> the landing page.  The landing page has three sections.  The first  
> section lists the surveys the respondent can currently complete (based  
> on the same availability logic found elsewhere in the app).  The  
> second section lists the surveys the respondent has had access to, but  
> does no longer.  For example, surveys that have moved to "done"  
> status.  The third section are "tools", where the respondent can  
> change their password, change their profile, get help, or log out.
> 
> I am not quite done with this.  I need to test a little more,  
> especially the LDAP part.  If anyone already has an LDAP environment  
> configured, I'd appreciate a test of this against your server.  I also  
> need to fill out the help pages.  Any review you can provide would be  
> appreciated.
> 
> I hope to have this patch finished in the next 24 hours.
> 
> Based on how the system is set up, there is one caveat to using the  
> landing page: <username,password> tuples must be unique throughout the  
> system.  Currently, the database says <username,realm> is unique, so  
> when entering a <username,password>, it's possible that the same  
> username in two different realms has the same password, in which case,  
> it's impossible to tell which user is which.  Right now, if the system  
> detects that case, the user is not allowed to log in.
> 
> 
> Thoughts?
> 
> bishop
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel

Re: [phpesp-dev] preliminary patch: respondent landing page

[Bishop B. <ph...@id...>]

Hi Matthew,

Quoting Matthew Gregg <mat...@gm...>:

> Sounds good except for username,password uniqueness.  Currently the way
> users are assigned to multiple realms is that they will have 2 entries
> with the same userid/password different realms(yes that is ugly, don't
> blame me for that :-)).

Yeah, the <username,realm>, instead of just <username>, uniqueness =20
issue really gets me.

Is the purpose of the realm to host multiple different survey groups =20
with the same code base?  That's my intuition, based on the code: the =20
division of css especially alludes to that.

If so, can't we just enforce a <username, password, realm> uniqueness? =20
  We could implement that transparently (to the user) by salting the =20
password with the realm.  In fact, it would be quite easy to implement =20
as there's already that password_upgrade() function that all =20
authentication goes through -- we just hook into that.


> Why not require that all the surveys on the landing page be in the same
> realm as the user logging in?

I can require that, certainly.  But, I need to know which realm to use =20
in the first place.  Does the user specify the realm from a drop-down =20
(like Windows domains)?  Or is the realm part of the system =20
configuration (like Kerberos)?

Neither one of those sounded good to me: one forces the user to make a =20
choice (bad), the other relies on an admin to do something right (less =20
bad, but still not optimal).

We could just salt the password with the realm, making the <username, =20
password, realm> tuple unique and bingo, problem solved.


> Does this patch build on the previous patches you've sent?  I hope to
> have time tomorrow to work on reviewing them.

Unfortunately, yes.  I'm doing all my patching to phpESP (that's =20
separate from client-specific coding) on a single branch, so I'm =20
building on the previous patches.  In this case, there's some overlap =20
in support files.


Let me know about the salt approach.

bishop

> On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
>> All,
>>
>> Attached is a preliminary patch to support a "landing page" for
>> respondents.  Here's how it works:  If use_landing =3D true in
>> configuration, then public/landing.php opens up.  That pages shows a
>> login box and any public surveys available in the system.
>>
>> A respondent enters their username and password, and if valid, goes to
>> the landing page.  The landing page has three sections.  The first
>> section lists the surveys the respondent can currently complete (based
>> on the same availability logic found elsewhere in the app).  The
>> second section lists the surveys the respondent has had access to, but
>> does no longer.  For example, surveys that have moved to "done"
>> status.  The third section are "tools", where the respondent can
>> change their password, change their profile, get help, or log out.
>>
>> I am not quite done with this.  I need to test a little more,
>> especially the LDAP part.  If anyone already has an LDAP environment
>> configured, I'd appreciate a test of this against your server.  I also
>> need to fill out the help pages.  Any review you can provide would be
>> appreciated.
>>
>> I hope to have this patch finished in the next 24 hours.
>>
>> Based on how the system is set up, there is one caveat to using the
>> landing page: <username,password> tuples must be unique throughout the
>> system.  Currently, the database says <username,realm> is unique, so
>> when entering a <username,password>, it's possible that the same
>> username in two different realms has the same password, in which case,
>> it's impossible to tell which user is which.  Right now, if the system
>> detects that case, the user is not allowed to log in.
>>
>>
>> Thoughts?
>>
>> bishop
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl=
ace
>> _______________________________________________ phpESP-devel  =20
>> mailing list php...@li...  =20
>> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpla=
ce
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] preliminary patch: respondent landing page

[Matthew G. <mat...@gm...>]

On Tue, 2008-01-15 at 08:17 -0500, Bishop Bettini wrote: 
> 
> We could just salt the password with the realm, making the <username,  
> password, realm> tuple unique and bingo, problem solved.
> 
I think this is the way to go, as long as it's done in a way that
doesn't effect existing data.
> 
> > Does this patch build on the previous patches you've sent?  I hope to
> > have time tomorrow to work on reviewing them.
> 
> Unfortunately, yes.  I'm doing all my patching to phpESP (that's  
> separate from client-specific coding) on a single branch, so I'm  
> building on the previous patches.  In this case, there's some overlap  
> in support files.
> 
> 
> Let me know about the salt approach.
> 
> bishop
> 
> > On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
> >> All,
> >>
> >> Attached is a preliminary patch to support a "landing page" for
> >> respondents.  Here's how it works:  If use_landing = true in
> >> configuration, then public/landing.php opens up.  That pages shows a
> >> login box and any public surveys available in the system.
> >>
> >> A respondent enters their username and password, and if valid, goes to
> >> the landing page.  The landing page has three sections.  The first
> >> section lists the surveys the respondent can currently complete (based
> >> on the same availability logic found elsewhere in the app).  The
> >> second section lists the surveys the respondent has had access to, but
> >> does no longer.  For example, surveys that have moved to "done"
> >> status.  The third section are "tools", where the respondent can
> >> change their password, change their profile, get help, or log out.
> >>
> >> I am not quite done with this.  I need to test a little more,
> >> especially the LDAP part.  If anyone already has an LDAP environment
> >> configured, I'd appreciate a test of this against your server.  I also
> >> need to fill out the help pages.  Any review you can provide would be
> >> appreciated.
> >>
> >> I hope to have this patch finished in the next 24 hours.
> >>
> >> Based on how the system is set up, there is one caveat to using the
> >> landing page: <username,password> tuples must be unique throughout the
> >> system.  Currently, the database says <username,realm> is unique, so
> >> when entering a <username,password>, it's possible that the same
> >> username in two different realms has the same password, in which case,
> >> it's impossible to tell which user is which.  Right now, if the system
> >> detects that case, the user is not allowed to log in.
> >>
> >>
> >> Thoughts?
> >>
> >> bishop
> >>
> >> -------------------------------------------------------------------------
> >> Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >> _______________________________________________ phpESP-devel   
> >> mailing list php...@li...   
> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 

[phpesp-dev] respondents, log in, and knowledge of the realm

[Bishop B. <ph...@id...>]

Comments follow below (trail included for reference):

Quoting Bishop Bettini <ph...@id...>:

mg>> Sounds good except for username,password uniqueness.  Currently the way
mg>> users are assigned to multiple realms is that they will have 2 entries
mg>> with the same userid/password different realms(yes that is ugly, don't
mg>> blame me for that :-)).
bb>
bb> Yeah, the <username,realm>, instead of just <username>, uniqueness
bb> issue really gets me.
bb>
bb> Is the purpose of the realm to host multiple different survey groups
bb> with the same code base?  That's my intuition, based on the code: the
bb> division of css especially alludes to that.
bb>
bb> If so, can't we just enforce a <username, password, realm> uniqueness?
bb>  We could implement that transparently (to the user) by salting the
bb> password with the realm.  In fact, it would be quite easy to implement
bb> as there's already that password_upgrade() function that all
bb> authentication goes through -- we just hook into that.

Earlier, I suggested that salting the password with the realm would =20
make <username,password> unique, and while that is true, it doesn't =20
solve the problem.

To use the dashboard, the user provides his username and password.  =20
But, a given <username,password> can match multiple respondents, all =20
in different realms.  If you don't know the realm, you don't know =20
which user has just logged in, which means you can't show a guaranteed =20
list of surveys unique to that user.

Salting the password with the realm won't help because you still don't =20
know what realm this user is in.

I think this username uniqueness issue is not only a problem with the =20
dashboard, but also with existing code.  I'm new here, so I may be way =20
off, so tag me if I'm off base:

FACTS:
1. A survey can have multiple realms accessing it (table=3Daccess)
2. Two respondents can have the same username and password, but =20
different realms (table=3Drespondent)
3. A response has a survey and a username (table=3Dresponse)


SCENARIO:
Suppose you have two respondents:
Username Password Realm
Joe      test     Foo
Joe      test     Bar

And one private survey with two realms accessing it:
Survey    Realm
MySurvey  Foo
MySurvey  bar

Now, Joe (in Foo) hits public/survey.php?name=3DMySurvey and completes =20
the survey.


PROBLEM:
Which Joe answered MySurvey?!?  This is what goes into response:

   Survey   Username
   MySurvey Joe

You can't know which Joe that is, because response presumes that =20
<username, survey_id> is unique, which isn't the case (because a =20
username isn't unique within a survey because a survey *can have more =20
than one realm*).

In fact, what occurs is that what applies for one applies for all: if =20
there's a max response of one, then Joe Foo's answer counts as the max =20
response, so when Joe Bar tries to respond, he gets:

[ Your account has been disabled or you have already completed this survey. =
]

Which occurs precisely because response can't tell the Joe's apart.


SOLUTION:
Either realm has to be added to response, so that the <username,realm> =20
key is unique, or <username> has to be unique.

Option #1, for existing deployments, requires back filling realm into =20
response, but that will fail if any survey grants access to more than =20
one realm that share a username (unless maxresponse happens to be 1 =20
for all surveys in question, then you can know which realm it is).

Option #2, for existing deployments, will require making usernames =20
unique, which can't currently be done from UI (because you can't =20
change a username once created, presumably to avoid changing history).


If I'm reading the code right, and that scenario is right, then there =20
is a bug in the data relationships of existing deployments that should =20
be fixed.  Do we have any idea of how many deployments are sharing =20
usernames across realms?  How many users does this affect?

I would just like to make require username uniqueness moving forward.  =20
That solves the dashboard problem and this bug henceforth.  Thoughts?

bishop

--=20
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] preliminary patch: respondent landing page

[Matthew G. <mat...@gm...>]

Thinking more about this...
On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
> All,
> 
> Attached is a preliminary patch to support a "landing page" for  
> respondents.  Here's how it works:  If use_landing = true in  
> configuration, then public/landing.php opens up.  That pages shows a  
> login box and any public surveys available in the system.
I don't like showing all public surveys, since in the general case most
surveys are "public" but hidden by the fact that the survey name is not
known. Why can't this page only be accessed after successfully
authenticating, then show only the info you talk about below?
> 
> A respondent enters their username and password, and if valid, goes to  
> the landing page.  The landing page has three sections.  The first  
> section lists the surveys the respondent can currently complete (based  
> on the same availability logic found elsewhere in the app).  The  
> second section lists the surveys the respondent has had access to, but  
> does no longer.  For example, surveys that have moved to "done"  
> status.  The third section are "tools", where the respondent can  
> change their password, change their profile, get help, or log out.
> 
> Thoughts?
> 
> bishop
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel

Re: [phpesp-dev] preliminary patch: respondent landing page

[Bishop B. <ph...@id...>]

Quoting Matthew Gregg <mat...@gm...>:

> Thinking more about this...
> On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
>> All,
>>
>> Attached is a preliminary patch to support a "landing page" for
>> respondents.  Here's how it works:  If use_landing =3D true in
>> configuration, then public/landing.php opens up.  That pages shows a
>> login box and any public surveys available in the system.
> I don't like showing all public surveys, since in the general case most
> surveys are "public" but hidden by the fact that the survey name is not
> known. Why can't this page only be accessed after successfully
> authenticating, then show only the info you talk about below?

I think it depends upon use case: some will not want to show all =20
public, while others will want to show them.  Since it can be easily =20
driven by a configuration option, I'll add that in.  Thoughts?

bishop

--=20
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems