Re: [Demexp-dev] logins and account creation.

[David MENTRE]

Hi Augustin,

Augustin <address@hidden> writes:

> On Saturday 07 October 2006 07:08 pm, David MENTRE wrote:
>> Ok, so I propose the following scheme:
>>
>>  * Fields visible to the user:
>>
>>    * Drupal login,
>>
>>    * Complete real name,
>>
>>    * Email address,
>>
>>    * Any field that might be necessary for other modules;
>
> This can be set up this way for stage 1. 
> Is the real name required?

Yes, this is our "identifier" for the person.

> (if so, it shouldn't be displayed on the user profile page for other
> users to see).

Obviously.

>>  * Fields not editable by the user (and managed by demexp admins):
>>
>>    * demexp server login;
>>    * demexp server password;
>
> I could live with that, but I am not sure it is the best approach.

I never claimed that neither. ;-)

> First, the reason why I stored the password in the $_SESSION[] variable 
> (refer 
> to earlier discussion), is precisely so that I wouldn't have to store the 
> password and reduce security risks. If it is stored, then the web admin (me) 
> has indirectly access to them, which is what you wanted to avoid. 

Yes and this is an issue. :-(

What do you suggest, that the user enters is demexp password and login
each time he starts making votes through the Drupal interface?

I don't like the approach from a usability point of view (even if the
web browse can easily store them conveniently and in a secure way) but
it could work for stage 1.

> I understand that your primary concern is to verify the identity of the 
> Drupal 
> users,  to ensure that the people are who they say they are.
> Unfortunately, you won't achieve it this way. 
> I can easily set up a drupal account "le_timide" (or "shy_dude") and write my 
> real name to be "Arnaud Pierre Edouard Fouquaut", a name that I have picked 
> up here: http://demexp.ouvaton.org/node/258 then you'd never know I am not 
> him.

Yes, we'll never be sure that a given account relates to the person
he/she pretend to be. Even with a big pile of paperwork. But we wan't at
least to increase the confidence in the person pretending being a rela
one.

> What's worse, if you setup the password for me, then I have direct 
> access to his voting record.

Well, we can imaging checking an email address or opening the account
through the email address.


> Have you kept all the mail addresses of the people who registered in the 
> demexp server? 

Yes.

> I hope stage 1 will be live by November 1st. Stage 2 should come soon after 
> that (say, two months later, January 1st). During this first stage, we won't 
> have that many users. What I am suggesting is that we keep the registration 
> process more or less the same way for stage 1 only.

I'll check your latest prototype and see if I can provide meaningful
suggestions.

> For stage 2, here is what we could do:
>  * The minimum we can do is set up an email confirmation procedure:
> a- user registers account with you. You send them by email account name, 
> password.
> b- user signs up for a web (Drupal) account (we'll have to make clear that 
> they are not expected to enter their demexp account name - some already tried 
> to do that on the test site).

Well a then b seems a bit complicated to me. Why not create the Drupal
account immediately? Or why not using a web form to ask for relevant
information and create demexp and Drupal accounts?
 
> c- before they can vote, they are asked to enter their demexp account.
> d- after they enter the account name, it is not yet activated but an email is 
> sent to you, saying: "a person pretending to be XYZ has signed up on the web. 
> Can you send him/her an activation key?"
> e- you send the activation key to the email that was used to request for the 
> account in step a. (all of this can be semi-automated)
> f- user receives email and confirms he's the same person (though we still 
> don't know if it's their real name... we won't know until we get a birth 
> certificate). His voting account is activated and now can use his web account 
> to vote, etc.


I like this email confirmation.

> g- I can make sure that the same demexp account can only be used once by 
> drupal users, i.e. the same user who got a demexp account in step a cannot 
> use the same account to set up two drupal accounts (why would one want to do 
> that is not clear since they still wouldn't be able to vote twice, but we 
> still can make sure this does not happen). 

Yes, this is necessary. Several Drupal accounts would let a user appears
as a crowd in a discussion.

>  * For stage two, also: we can review the account registration procedure. I 
> would like to propose something new (better?) that can be discussed later. If 
> people agree on the new scheme, it will affect the web procedure, too.

Ok. 

>>  * demexp-server-login is derived from Complete-real-name with a simple
>>    encoding scheme (e.g. URL encoding of UTF-8 or any other valid
>>    canonical pure ASCII form);
>
> See reply above. 
> Also, stage 1 assumes no changes are made on the server, so it can be 
> implemented quickly. 

Ok, I keep my proposal for now. But I migt suggest something even for
stage 1.

> done, thanks. :)
> Can you set up the same account on the test server? I will need it.

Done: login 'augustin', password 'augustin', with classifier and admin
rights.



>> The only difference is that, instead of filling the demexp server login
>> and password they would have a button saying: "give me a login/password
>> to vote". What do you think of it?
>
> What I propose above is that they will be given a validation key instead, 
> that 
> will ensure that the person who registers on the web is the same who got the 
> demexp account from you. 

A validation procedure through an email is obviously a first step.

I need to think more about all of this.

Best wishes,
d.
-- 
GPG/PGP key: A3AD7A2A David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A