[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Demexp-dev] logins and account creation.
Re: [Demexp-dev] logins and account creation.
Sun, 8 Oct 2006 10:25:08 +0800
It seems we are making some progress here... :)
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? (if so, it shouldn't be displayed on the user
profile page for other users to see).
> * 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.
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.
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. What's worse, if you setup the password for me, then I have direct
access to his voting record.
Have you kept all the mail addresses of the people who registered in the
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.
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,
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).
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.
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).
* 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.
> > The display name is the login name.
> Ok, I agree: the display name is the Drupal login name.
> I still have one question: is it possible to change the Drupal login
> (and thus the display name) while keeping the same Drupal account?
> Has Drupal an internal identifier for Drupal logins?
> > If the accounts are created not manually but programmatically, then the
> > elected pattern Prénom.Prénom2.Prénom3.NOM (en encodage UTF8) is making
> > too many cultural assumptions.
> Yes, this is too difficult.
> So I propose following scheme:
> * 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
During stage 2, I'll make a complete proposal and I'll see what you all think
> * once a demexp login has been assigned to a Drupal account, this login
> should be kept, even if Complete-real-name is changed.
yes, something like that can be arranged.
> You right that association between real identity and internal demexp
> identifier should be separated, but this need more thoughts to be
> correctly done.
> > Do you realize that I still don't have a demexp account?
> You should fix that. ;-)
done, thanks. :)
Can you set up the same account on the test server? I will need it.
> > If we make it easier for people to join the discussion and take part in
> > the community life, they'll start giving their own opinion on topics
> > which will lead to a vote... and by the time they are interested enough
> > to actually vote, they will be greeted by a form saying "please enter
> > your demexp account name and password".
> I like this approach.
> 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.
> > Most obviously, there is no consensus on this whole point.
> I hope we're moving towards a consensus. :-)
yes. thanks :)
Our respective goals are the same, so it helps!
Because we and the world need to change.
Intimate Relationships, peace and harmony in the couple.
Revolutionary Psychology, White Tantrism, Dream Yoga...
Condorcet, Approval alternative, better voting methods.