[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