Victor Engmark wrote:
> Davi Leal wrote:
> > The field will contain the last time stamp of the lost-password or login
> > forms use, for such entity. What do you think about?
> >
> > E1_LastTimeStamp timestamp,
>
> If the table is named something like PasswordRetrieval, yes. It should be
> obvious from the table and column name what it contains.
It is not just for password retrieval, we have to use too for the
register forms, due to they has the same security problem.
True! By the way, I think it should be possible to register both a person and a company under the same email address - It's sure to be interesting for some individuals,
e.g., startups. I propose to split E1_Entities into one table per entity type, and create an entity view if necessary.
What I propose is to add the above new field to the E1_Entities data
base table, and use it to save any of the below time stamps:
1. The last timestamp related to Lost_Password.php, and
2. The last timestamp related to
Person.php, Company.php or
non-profit_Organization.php register forms.
I propose too this second case (2.) due to the Person.php,
Company.php & non-profit_Organization.php register forms has too
the same security problem, due to when a new user try to register
to the web site, if the email she want to use is already at the
data base, those forms shows a warning:
"You can not use it, ... that email is already used
in the data base ..."
What do you think?
Good idea! Actually, it looks like we'll have to have two steps in the registration process, separated by an email to the address provided with either a validation link or an error message. Still protects the user's privacy, but with a bit more hassle. I guess we should have a FAQ item for people receiving multiple registration emails or error messages. In the case of an error message, the user probably should just be pointed to the password retrieval page.
P.S.: You could take a quick look at the E1_Entities table,
Layer-0__Site_entry_point/doc/GNUHerds__SQL_Implementation.psql
Thanks!