Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

User/Contact name VS new login field

2010-01-18
2013-03-08
1 2 > >> (Page 1 of 2)
  • Hello,
      The field Adempiere uses for logging into the system is ad_user.name. This means that the name of a person is also used as a loginname for logging in.  These are two different purposes for a single field and I find these two purposes a bit incompatible:

    - On one hand you want a compact name to log in (for instance jsmith) but on the other hand you want a long and descriptive name for the person (ie John Smith or even worse with a name like Jose Antonio Rodríguez Martínez which is a very common Spanish name).

    - Language specific characters represent another problem. A name may be Jürgen Düsselforf or Noé Muñiz Martínez, but the characters ü, é, ñ, í are not easily available (if at all) from any computer you may want to log in. Instead of that you want to log in with something simple like jdusseldorf or noemuniz.

    -A third problem that I can see is that you can have several users/contacts with the same name (you may have more than one John Smith or Pepe Sanchez). That's common in real life and you can enter that in Adempiere since there isn't any restriction in the database to force unique values.
    In this scenario I don't know how Adempiere will react when two different users with the same name try to log in into the system.
    Don't you think it will be much easier and simple to use another field for logging in so you can assing a different loginname even though they have the same real name?  (For instance jsmith1 and jsmith2 or jsmith and johnsmith).

    I will really apreciate if someone can explain me how Adempiere solves this problem.
    Why Adempiere has only one field for these two different purposes? Am I missing something?

    Thank you very much

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-18

    Hi Enrique.  I see this is your first post here - welcome to Adempiere!

    I agree with you.

    Easy way could be to validate against ad_user.value instead of name (we could add that as a configurable parameter).

    But even in such case we still have the problem of guaranteeing uniqueness on value.

    And the problem can be extended - you would need to guarantee uniqueness on the database (not at client level) - so this can be a "problem" for multi-tenant installations.

    I just tested creating a new company, and creating a GardenAdmin user (same password) in the new company - it worked with problems - the GardenAdmin can log in to the new company - but the #AD_User_ID is set for the GW ID.  So - it seems like a bug here.

    OTOH - to log in webstore the e-mail is used - maybe we can use e-mail also as log in field (again - with the problem of guaranteeing uniqueness)

    Regards,

    Carlos Ruiz

     
  • Hello Carlos,
       first of all thank you very much for welcoming me to Adempiere and also for answering my post so quickly!
    I have been reading the Adempiere forums for a while and I never expected to get an answer from a "Big Gun" like you :-)

    Moving back to the point, I liked your detailed answer but I'm not sure if I understood it properly.
    To solve problems 1 and 2 you suggest to validate against ad_user.value instead of name which I think is a very good idea but I have been reading the code and I don't think that change is that straight forward. I had a look at Login.java and I could see ad_user_id spreaded all over the file and also in some other files. I'm afraid I don't know Adempiere code much so maybe I'm wrong. Do I have to make all those changes or is there an easy way of doing it?

    Do you think I should do this change just for myself or do you find it useful enough to update Adempiere so everyone could benefit of it?

    Regarding the uniqueness problem, you are right, you need to guarantee uniqueness on the database since when you log in you don't specify the client (you do it afterwards, on the second tab). It's imposible to achieve that using the name filed but could be easy using the value field (or another field created for the login purpose only). A database restriction could be added for that.

    Finally, I'm not sure how good is to use email for logging since some companies use general email addresses like vendors@aa.com or info@bb.com  instead of having a single email address for each of their employees and that's the only email you have to contact the users/contacts.

    Thank you

     
  • Norbert Bede
    Norbert Bede
    2010-01-20

    We had used several years ago salesforce.com multi-tenant SaaS service. In their system login possible only with email address.
    Uniqueness on the database and simple login in ADempiere should quareanteed same way, with email. An email address is allways unique.

    Another systems for example liferay has the same solution.

    norbert

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-20

    Hi, some deeper research on this.

    1 - LDAPUser is the column intended for such behavior

    2 - I guess there are currently some inconsistencies in Adempiere that can be treated as bugs:

    * MUser.get(ctx, user, password) is behaving different than Login.getRoles(user, password, force)

    * If two users have the same entry key for COALESCE(LDAPUser,Name) and the same password the system assigns incorrectly the user ID - so uniqueness must be guaranteed on database for COALESCE(LDAPUser,Name)+Password

    IMHO, a complete solution can be:

    - make LDAPUser mandatory for users with password (with corresponding migration scripts)
    - validate log in exclusively with LDAPUser field
    - make consistent MUser.get with Login.getRoles to use LDAPUser
    - in MUser.beforeSave validate uniqueness through the whole DB on LDAPUser+Password
    - Check for the same uniqueness on the process UserPassword
    - Apply the same behavior for webstore users - by default the auto-created webstore users can save e-mail on LDAPUser and validate its uniqueness
    - AdempiereMonitorFilter.checkAuthorization must check also with LDAPUser instead of Name
    - AdempiereMonitorFilter and web store must validate against encrypted or non-encrypted passwords depending on the value of column_ID=417 (as Login is doing)

    Regards,

    Carlos Ruiz

     
  • Hello,
      I don't quite agree with using the field LDAPUser since it is meant for login in through an LDAP server.
    We have decided to implement the login creating a new field called ad_user.loginname.

    I find this is an important issue in Adempiere and I believe something (one solution or another) should be implemented in the trunk. I'll be happy to help with this implementation but aparently the comunity doesn' t seem to find this as important since no one wrote anything here for the last week.

    What do you think Carlos and Norbert? is this going to die here buried in the forum?

    Cheers,
    Enrique Cartagena

     
  • Hi Carlos,

    uniqueness must be guaranteed on database for COALESCE(LDAPUser,Name)+Password

    I think that this leads to problems. How do you implement the Forgotten password case? If user forget his password then you can't send him back his password as there are two users with the same login name.

    Propasal by Enrique sounds good for me:

    adding ad_user.loginname

    So i would vote positively for this approach.

    In other post related to this problem someone have described the idea to add new field to AD_Client table: loginString, or something similar. Idea was that this is a text field which user enter at initial login screen. This field is used to lookup the AD_Client record. And after that using AD_Client_ID + AD_User.Name or AD_User.Value lookup the AD_User_ID.

    Both approaches are possible, but i think that second is not so common and users will not like it.

    @Enrique, can you please try to implement your idea and create patch? I'm willing to work on it and integrate it in trunk.

    Regards,
    Trifon

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-26

    Hi Enrique,

    > I don't quite agree with using the field LDAPUser since it is meant for login in through an LDAP server.

    I'm not "proposing" a solution, I'm stating that this is already implemented this way since Compiere times.

    I tested and it solves one part of the problem, if you fill LDAPUser then this is used to log in on swing client and zkwebui client.

    > We have decided to implement the login creating a new field called ad_user.loginname.

    About your personalization I just can advice.  I won't recommend you to implement another field when currently exists one to solve the same need.  (duplicate functionality)
    ________________

    Trifon

    >> uniqueness must be guaranteed on database for COALESCE(LDAPUser,Name)+Password
    > I think that this leads to problems. How do you implement the Forgotten password case?

    Sorry, I don't see the relation between a uniqueness validation and a mechanism to implement "remember my forgotten password" - I can't see how they correlate or interfere.

    BTW - I'm saying that unique validation is a need because currently Adempiere behaves wrongly if two users on different clients (tenants) have the same LDAPUser/Name and same password - I tested and it leads to data errors - so it can be considered a prio 9 bug.

    Regards,

    Carlos Ruiz

     
  • @Carlos,

    >> uniqueness must be guaranteed on database for
    COALESCE(LDAPUser,Name)+Password
    > I think that this leads to problems. How do you implement the Forgotten password
    case?

    Sorry, I don't see the relation between a uniqueness validation and a mechanism
    to implement "remember my forgotten password" - I can't see how they correlate
    or interfere.

    Your proposal to make (LDAPUser,Name)+Password Unique will lead to problems when user forget his password as system will not be able to identify uniquely user.

    Trifon

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-26

    Trifon, now I see the source of the confusion, let me explain it better:

    > Your proposal to make (LDAPUser,Name)+Password Unique
    > will lead to problems when user forget his password as system
    > will not be able to identify uniquely user

    At this moment AD_User table (User and Contacts in Adempiere terminology) doesn't have any uniqueness validation, it just have the common primary key AD_User_ID - the internal ID used by Adempiere.

    This is partially OK - as you can create many contacts with the same name - there can be many Trifon Trifonov working in different companies - and the user table doesn't validate uniqueness on name - indeed it doesn't validate uniqueness in any column.

    Now, talking about users with password there are three kinds:
    - ADempiere users -> with a password and a role
    - Webstore users -> with a password and e-mail, and without a role
    - ADempiere+Webstore users -> with a password and e-mail and a role

    The problem is that for users WITH password the lack of uniqueness validation is a problem.  It's a mistake to have two USERS with passwords with the same name on a company - it can lead to audit problems - but the problem is even worst if you have the same USER (name or LDAPUser) with the same password - even on different companies it leads to data problems.

    So, what I'm pointing to is the need to add a validation (still don't know where is the best place) to control the uniqueness of users with passwords within a company - and even within several companies on the same database.

    Regards,

    Carlos Ruiz

     
  • @Carlos

    I know situation quite well.
    Faced it 2 times in last 3 years on customer sides.
    Workaround is quite easy and unfortunately companies didn't committed resources to fix it.

    I still think that proposal to add new Unique column into AD_User table is the solution into long term.
    Hope that Enrique can collaborate more and resolve it together.

    Regards,
    Trifon

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-26

    Trifon,

    > Workaround is quite easy

    Can you share it with us?

    > I still think that proposal to add new Unique column into AD_User table
    > is the solution into long term.

    Why a *new* Unique column if there is already one that represents exactly the same functionality?

    Regards,

    Carlos Ruiz

     
  • > Workaround is quite easy

    Can you share it with us?

    Yes. Don't create two user with the same Name belonging to different Tenants.

    Why a *new* Unique column if there is already one that represents exactly the same functionality?

    Which column in AD_User table is defined as unique now?

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-27

    Hi Trifon,

    >>> Workaround is quite easy and unfortunately companies didn't committed resources to fix it.
    >> Can you share it with us?
    > Yes. Don't create two user with the same Name belonging to different Tenants.

    Really?  That's the workaround that companies didn't commit resources to fix it?
    I like your humour  :-)

    >> Why a *new* Unique column if there is already one that represents exactly the same functionality?
    > Which column in AD_User table is defined as unique now?

    Read above.

    Regards,

    Carlos Ruiz

     
  • Teo Sarca
    Teo Sarca
    2010-01-27

    Hi all,

    Here are my opinions about this topic:
    * I think is better to use a new column like username then LDAPUser, because the LDAPUser column has a very good meaning. But anyway, I think is better if we can have a solution like other SaaS, take for example google apps. When you login, you need to provide the company domain too. So I think is better if we display the Tenant (Client) field on first login tab. Using that field the user can specify on which tenant he/she wants to login. The tenant field should be configurable using a sys config variable, if we want a combo box (and the user selects from there) or we want a text field and the user write there the company name/domain/id/etc.

    * including AD_User.Password in a unique index it's a bad approach and can lead to a lot of issues. Do not include in a unque index something that is changing so frequently and on user desire.

    * in a true SaaS environment we should be able to have 2 users on different Tenants with exactly same email, name etc.

    What do you think?

    Best regards,
    Teo Sarca

     
  • Hi Teo,

    Yes, i agree with you!
    This is the best solution to have true SaaS ADempiere so one user can login with the same Name into different Tenants.
    My vote is

    Regards,
    Trifon

     
  • Hi Teo,

    +1 from me.

    Regards,

    Armen

     
  • Norbert Bede
    Norbert Bede
    2010-01-27

    HI,

    I'm not a programmer - i'm business consultant. I dont know ADempiere fields  and mechanism on developer level,  but I want share my experiences from liferay, otrs and salesforce.com SaaS LDAP setup.

    OTRS
    there is a main setup, related to ldap in perl, where you can setting up fields mapping. this mean user can set which data will appear in which database in which field. System should works in two mode: true LDAP - no synchronisation availablie on login system directly ask for username and password to ldap server. second - preferred mode - by me: where ldap synchronise user database with ldap. There is one way synchronisation.

    liferay
    same as otrs - possible synchronisation but two way. Users should login with username (uid) or with email with domain (same as google or salesforce.com)

    I think login with unique email address is the most accepted method and also from todays users.

    norbert bede
    slovakia

     
  • Hi,

    At this point i would like for voting in order to understand what is suitable for most of the users of ADempiere.
    As we saw we have two options:
    1) Make User email unique and login with email.
    2) Make ADempiere truly SaaS and ask for additional info(Tenant related) on the login screen and user name/email. This means making multi unique constraint at DB level. Tenant = User.Name/USer.Email.

    Any other options or comments?

    Regards,
    Trifon

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-27

    Enrique - 19 answers to your post - apparently the community found this as important.

    So, there are two proposals now - how much it cost the workaround provided by Trifon?  Maybe I'm willing to sponsor it  :-D
    Sorry, just joking.

    Now seriously, answering Teo that made a serious proposal:

    > * I think is better to use a new column like username then LDAPUser,
    > because the LDAPUser column has a very good meaning.

    We'll have duplicated columns with the same purpose - another possibility is to rename LDAPUser if the name is what is becoming problematic for you.  I mean LDAPUser is a login string currently used in adempiere, what's the value to add a second login string?

    > But anyway, I think is better if we can have a solution like other SaaS,
    > take for example google apps. When you login, you need to provide
    > the company domain too.

    Yep, I remember something similar was proposed by Michael here:
    https://sourceforge.net/projects/adempiere/forums/forum/610546/topic/1923663?message=4761525

    > So I think is better if we display the Tenant (Client) field on first login tab.
    > Using that field the user can specify on which tenant he/she wants to
    > login. The tenant field should be configurable using a sys config variable,
    > if we want a combo box (and the user selects from there) or we want a text
    > field and the user write there the company name/domain/id/etc.

    It sounds feasible - this is a very good thing to test the proposed PMC Structure as it has serious implications on:
    - Architecture: Compatibility with other systems (i.e. 3E_WebServices will be affected)
    - Functional: Check backward compatibility, check behavior on webstore vs normal clients (swing and zk)
    - Usability: Ease of use
    - Security: Exposing the names of tenants on login is a risk to evaluate

    So, this is one of those topics that has many edges and it's important to ensure we're covering all points of view.

    We can try to exploit this good use case to review how the PMC Structure can work on these kind of proposals.

    > * including AD_User.Password in a unique index it's a bad approach and
    > can lead to a lot of issues. Do not include in a unque index something that
    > is changing so frequently and on user desire.

    IMHO, you're right on the assumption, but wrong on the reason.  Including AD_User.Password is not the best solution, and it's more like a hack I proposed, your solution can be a lot better.  My reason to think it's bad is because of security issues.

    > * in a true SaaS environment we should be able to have 2 users on
    > different Tenants with exactly same email, name etc.

    Agree, and we must try to find a good solution for this.

    So, summarizing, I like Teo's proposal - but I would recommend deeper review from the many edges the issue has.  I can try to use this as a first test for the PMC Structure.  BTW, participation on the PMC is open, it's not a closed circle, so it's up to you to sign up on the group you think you can be helpful.

    WDYT?

    Regards,

    Carlos Ruiz

     
  • Carlos,

    we can expose a String from AD_Client. We can define new unique column in AD_Client which can hold any string in order to obscure Tenant name. Exposing Tenant name at initial login screen will not be something which all companies will like.

    I ask for community voting as i want to understand what most of the ADempiere users think and want to see in ADempiere. PMC or whatever else group is much smaller then ADempiere community.

    Trifon

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-01-28

    No, no, Trifon.  I'm not criticizing to call for community vote. I'm ok with that.

    Indeed it will be GREAT if we start using ideatorrent here to cast votes from community and start creating a good wishlist:
    https://sourceforge.net/apps/ideatorrent/adempiere/

    Vote from community can guide us to prioritize where we must focus our efforts, but it's just obvious that just votes are not helping us in the analysis of:

    - Architecture: Compatibility with other systems (i.e. 3E_WebServices will be affected)
    - Functional: Check backward compatibility, check behavior on webstore vs normal clients (swing and zk)
    - Usability: Ease of use
    - Security: Exposing the names of tenants on login is a risk to evaluate

    There is a difference between "yes, I like it" - and a proper design process to solve things in the best way.  I'm not proposing to replace forum discussion - discussing design in forums has always helped us.  I'm just thinking to improve the process in order to ensure that we always take into account ALL the edges of a problem.

    Regards,

    Carlos Ruiz

     
  • Hi,
    first of all thank you very much for all your comments to this post. I really apreciate all the time and effort you put to analize the problem and suggest diferent ways of solving it.
    During all this time I have not been writing any comment but I have been reading yours eagerly because you are truly experts in Adempiere which I'm afraid I'm not.
    The SAAS option looks like a very good one.

    Now I can see two things here:

    1- I have a problem that I need to solve and that's the reason why I started this thread. Our company is implementing Adempiere with the help of another IT company. We need the fix so we have implemented the login using a new field called loginname.
    This solution works well for us but I believe this is an important feature and I believe it should be in the trunk, not in a local customization. In addition to that it should be done properly, not just a quick fix like we have done.
    On the other hand at this point in time we don't have the knowledge or the resources to do it ourselves. We are under big pressure from the business side to meet our deadline. We have never done a change in the trunk and I'm sure there is a learning curve for that (Adempiere has proved not to be easy to learn). Once you do it once I bet it's easy and straight forward but not the first time.

    2- You have done really good analysis work here and it seems that it has ended here (after 10 days of no more comments). As I said in a previous comment this is going to die here buried in this forum and the good work will be lost, and a few months later someone will face a similar situation and the whole thing will start again in a different thread and it may die again, ….
    I believe this is happening not just with this problem but with many others in the forum.

    I think that's a big problem that Adempiere has and focusing now in solutions  I believe Carlos Ruiz made a very good suggestion.
    We could use ideatorrent as he suggests, or Mantis, or Bugzilla, or whatever suits the needs. This way everything related to a problem/feature will be in a single place and not scatered along comments in threads in the forum where is not easy to search for info by the way.
    So a single place where to store comments, suggestions, votes, architecture, functional, usability, security, proof of concept, tests, scripts, …

    It may happen that once a lot of info for a problem is stored there it doesnt get implemented but next time someone has a need to that feature/problem it's only a matter of going back to that single place and continue from where it was left last time until it finally gets implemented.
    Once Adempiere goes into production in our company I will love to go back to this problem and implement it properly and get rid of our fix. I definitly would like to contribute to this comunity.

    What do you think?

    Once again thank you very much for all your comments and for making Adempiere a world class ERP.
    Enrique Cartagena

     
  • Carlos Ruiz
    Carlos Ruiz
    2010-02-09

    Hi Enrique,

    I would recommend you to:

    1 - open a feature request tracker and contribute your patch

    2 - as you said I think your patch is a quick-fix and probably it needs deeper review of implications to arrive into a release, but it can be a seed point to check collaterals

    3 - I'm organizing PMC (really slowly) and probably I'll try to use this small issue to check the interaction between different groups - but nothing is defined here

    Regards,

    Carlos Ruiz

     
1 2 > >> (Page 1 of 2)