[
https://issues.apache.org/jira/browse/OFBIZ-4983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620759#comment-13620759
]
Harsha Chadhar edited comment on OFBIZ-4983 at 4/3/13 9:18 AM:
---------------------------------------------------------------
Also please provide suggestion that in which data file we can include the demo
data provided above.
was (Author: harshac):
Also please provide suggestions that in which data file we can include the
demo data provided above.
> New feature to reclaim a user account - Using Security Questions
> ----------------------------------------------------------------
>
> Key: OFBIZ-4983
> URL: https://issues.apache.org/jira/browse/OFBIZ-4983
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Harsha Chadhar
> Fix For: SVN trunk
>
> Attachments: 1.png, 2.png, 3.png, 4.png, 5.png, OFBIZ-4983.patch
>
>
> *Referring to Vikas's proposed model on Reclaiming User Account using
> security questions as follows :*
> "When a customer create an account on eCommerce site, he will also
> need to answer few security questions. We can enforce restriction on
> the minimum number of questions that must be answered by a user before
> creating his profile successfully, through some configurations which
> are discussed in the next section. These security questions then can
> be used to reclaim the customer account in case he forget his
> password. User can also be given a choice to add his own custom
> questions and this would be enable/disabled again through some
> configurations.
> If the user correctly answer minimum required questions while
> reclaiming his account, password will be send through email
> notifications. This part would work in the same way as the existing
> functionality of email password (forget password)."
> We would probably need the screens to configures
> 1) Security Question in the system.
> These questions will be called as Standard security questions and can
> only be entered by an admin (or a person with similar sort of
> privileges). These questions will be available to every user who
> create or update his profile.
> 2) Giving user an option to create his own custom security questions.
> A configuration/property that would determine whether this option is
> available to the user or not. These questions will be called as Custom
> security questions and can entered only by a user while creating or
> updating a profile. These questions will be available and applicable
> only to the owner of the questions, i.e the user who create these
> questions.
> 3) Minimum number of questions that are required to answer.
> This configuration/property would determine minimum number of
> questions that a user must answer while creating an account and as
> well as reclaiming an account.
> I think we can save above (#1, #2) configuration in database and
> provide screens to configure them. IMO, these configuration can be
> also called as a security configuration, since they are some how
> related to security.
> At this moment I have not much idea about where these sort of
> configuration should be saved but this could be part of the entity
> that saves the security configurations (which does not exist at this
> moment). In recent days certain properties are moved to entities and
> this could certainly be the done with security properties at certain
> point of time, until then these configuration can be kept under
> security properties file.
> Custom Data Model:
> The new entities that would be required for this feature are following
> (Scott did help in improving the data model few months back):
> SecurityQuestion: Security Question in the system. These questions can
> be standard (added by admin and are visible/available to every new
> user while creating a new account) as well as custom questions (added
> by a user). We can differentiate between the type of questions using
> questionTypeEnumId (STANDARD or CUSTOM) as defined in the data model
> below.
> PartySecurityQuestion: All the questions that are related to a User.
> They can be mix of both Standard as well as Custom.
> UserLoginSecurityQuestion: An entity to capture the answer of the
> security question and tying it to a UserLogin very much like a
> UserLoginSecurityGroup. When a User reclaim his account, the question
> answered by this user would be matched with the answer of the
> questions (corresponding to that user) in this entity.
> <entity entity-name="SecurityQuestion" package-
> name="org.ofbiz.security.login">
> <field name="questionId" type="id-ne"></field>
> <field name="questionTypeEnumId" type="id-ne"></field>
> <field name="question" type="very-long" ></field>
> <prim-key field="questionId"/>
> <relation rel-entity-name="Enumeration" type="one" fk-
> name="SECQ_ENUM" title="QuestionType">
> <key-map field-name="questionTypeEnumId" rel-field-
> name="enumId"/>
> </relation>
> </entity>
> <entity entity-name="PartySecurityQuestion" package-
> name="org.ofbiz.security.login">
> <field name="questionId" type="id-ne"></field>
> <field name="partyId" type="id-ne"></field>
> <prim-key field="questionId"/>
> <prim-key field="partyId"/>
> <relation rel-entity-name="SecurityQuestion" type="one" fk-
> name="PTYSECQ_SECQ">
> <key-map field-name="questionId"/>
> </relation>
> <relation type="one" rel-entity-name="Party" fk-
> name="PTYSECQ_PTY">
> <key-map field-name="partyId"/>
> </relation>
> </entity>
> <entity entity-name="UserLoginSecurityQuestion" package-
> name="org.ofbiz.security.login">
> <field name="questionId" type="id-ne"></field>
> <field name="userLoginId" type="id-vlong-ne"></field>
> <field name="question" type="very-long"></field>
> <field name="answer" type="short-varchar"></field>
> <prim-key field="questionId"/>
> <prim-key field="userLoginId"/>
> <relation rel-entity-name="SecurityQuestion" type="one" fk-
> name="ULGNSECQ_SECQ">
> <key-map field-name="questionId"/>
> </relation>
> <relation rel-entity-name="UserLogin" type="one" fk-
> name="ULGNSECQ_ULGN">
> <key-map field-name="userLoginId"/>
> </relation>
> </entity>
> </entitymodel>
> *As per David's Comments :*
> This looks like a great enhancement and this write-up is well thought
> out. Thanks for sharing it and soliciting feedback.
> About the data model, I'd recommend leaving out the
> PartySecurityQuestion entity. It introduces a dependency on the Party
> entity which is in a higher level component, and it appears that the
> UserLoginSecurityQuestion entity is adequate and since authentication
> is a UserLogin thing (and not a Party thing) it is better and makes
> more sense there anyway.
> -David
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
