• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

sso and database synchronization

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings,

I'm trying to integrate JForum into an existing webapp with its own user database and authentication. I've been reviewing the SSO techniques and have some questions.

My customers already have an account on my web site with their name, password, e-mail, and a unique numeric id. In looking at using sso, it appears that I can provide JForum with a user name (and optionally a password and e-mail) and JForum will automatically create an account for that user.

I assume that JForum does this by adding a record to the jforum_users table just as if the user registered via JForum. So what happens if my customer later changes their name or e-mail address? I assume that those values in jforum_users will be out-of-sync with the customer's account.

Is this a potential problem? Can it be solved by modifying JForum so that it obtains the user_name and user_email fields directly from the primary account database? Would I attack this by subclassing UserAction, UserDAO, or is there some other solution?

[originally posted on jforum.net by jbucanek]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another issues that's nagging at me is that SSO.authenticateUser() returns a user name. User names in our database are not unique. So if an SSO implementation returns an ambiguous user name, how can I can prevent JForum from using the wrong account?
[originally posted on jforum.net by jbucanek]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another issues that's nagging at me is that SSO.authenticateUser() returns a user name. User names in our database are not unique. So if an SSO implementation returns an ambiguous user name, how can I can prevent JForum from using the wrong account?
[originally posted on jforum.net by jbucanek]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Take a look at the DataAccessDriver and UserDAO interfaces. You can write/override them to do what you want. (I did it for my app).

You will also need to consider how to handle the jForum profile function. You may not want users changing some of the info via that screen. At a minimum, you will need to edit the profile.htm template. But for security, you may want to disable some of the field updating in the DAO just in case.

As to SSO and a single name, you have to have some way of uniquely identifying the user from the request. I'd suggest figuring a way to have the SSO return a "fully qualified name" and then in your UserDAO.selectByName() method populate the jForum user object name with this. That way the user names displayed in Jforum are unique.


[originally posted on jforum.net by monroe]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the tips, monroe.

I was trying to attack this by redefining the account names, but knew I was headed for trouble because so much of JForum wants to display the user_name and use it as a key. But now it occurs to me that I can override UserDAO.selectByName() and still leave the user_name alone. I can have SSO.authenticateUser() return a nick name like "#<account_id>#" and have selectByName() recognize that and perform a disambiguous lookup. For compatibility, it can fall back to performing a simple name match otherwise.

I'll take a look at DataAccessDriver and UserDAO and see if I can populate those User properties from my database. One more question: How do I replace the existing UserDAO with my subclass? Is there a factory method somewhere, or is this controlled by a properties file?
[originally posted on jforum.net by jbucanek]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is controled by The *DataAccessDriver class

You can subclass it and override the newUserDAO() method, and then register your DataAccessDriver in the configuration file.

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Grow your own food... or this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic