Brett,
This opens up the possibility to solve another problem - supporting
alternate authentication systems (like LDAP, etc).
Right now the userLogin entity includes OFBiz credentials (login name,
password), LDAP credentials (DN), and some other credentials that Andrew
added. From my perspective, it might be best to use the UserLogin entity
only for persisting a user, and have the credentials stored in another
entity. The UserLogin entity could then support any number of
authentication schemes:
UserCredentials
---------------
userLoginId*
authenticationTypeId*
fromDate*
thruDate
loginName
password
Would something like that solve your problem?
-Adrian
On 2/19/2012 6:51 AM, Brett Palmer wrote:
Sakthi,
Thanks for the quick reply. The system generated UserIds would not be
visible to the user. They would just be used by the system to use ofbiz
existing authentication and security features.
Our application is not a typical ecommerce app but one that is used by
students and teachers for testing. The students are suppose to use their
personal userID assigned to them but these are often not remembered and so
errors occur.
Here is what I am proposing for our solution:
1. Add new fields to the UserLoginId table that will allow us to determine
uniqueness within their particular organization. For example, a district
ID and a studentID.
2. Create custom authentication method to handle the de-references of the
student's studentId and districtId to determine the actual system Id.
3. Verify the password matches the one in the UserLogin table.
5. Get the UserLogin GenericValue and store in a session so ofbiz
authentication and security features work.
Now when a person calls to say their userId was incorrectly entered we can
quickly update their UserId because the ID the student uses is not the
primary key.
Let me know if anyone sees anything wrong with this approach.
Brett
On Fri, Feb 17, 2012 at 5:57 AM, Integrin Solutions<[email protected]
wrote:
Brett -
My thoughts -
- System generated UserIds might be hard for the users to remember;
- Changing UsersIds of a Person is not that difficult afterall; You
might want to assign a new UserId to the User<from PartyManager> and
disable the existing one;
- Sakthi
On 2/17/12, Brett Palmer<[email protected]> wrote:
We have an application based on the ofbiz framework for online testing.
We
use the ofbiz user authentication and userLoginId as designed by ofbiz.
The problem is that often teachers and students incorrectly register in
the system with a specific userId. Then they call up and want to change
their userId because it doesn't match their actual ID. It is difficult
to
change the userLoginId for a person once it has been assigned to a
person.
We would like the UserLoginId to work similarly to how the PartyId works.
PartyId is a system generated ID that is assigned to a Person,
PartyGroup,
etc. As a system generated ID it gives us a lot of flexibility in how it
is used. It also allow us to make changes easily like changing a
person's
name, etc.
A few months ago there was some discussion in the forums about
alternative
to how UserLoginId is used in the system. Has anyone come up with an
alternative to the default implementation of UserLoginId.
Thanks in advance for your suggestions.
Brett
--
Sent from my mobile device
