wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes designing a authentication mechanism Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "designing a authentication mechanism" Watch "designing a authentication mechanism" New topic
Author

designing a authentication mechanism

pendse anagha
Ranch Hand

Joined: Mar 09, 2005
Posts: 44
Hello ,
I am designing a system which is supposed to be shared across multiple applications .

While authenticating - I am supposed to check :

1 >Is the user present in the database
2 >Is the user active ( "status" field in database )
3 >Is the application active ( "status" field in database )

So one approach I was thinking was -
I would always get a Value Object ( DTO )
This object would have attributes such as -
"isAppPresent" , "isAppActive" , "isUserPresent" , "isUserActive" etc

Based on these attribute values - I would display the appropriate message on the UI

The other option is - write three exception classes - "ApplicationInactive" , "UserInactive" etc

Was wondering - should I throw exceptions and based on my exception logic deal with the situation or look at my Value Object attributes and take a decision ?

Thanks in advance ,
-anagha
Vishnu Ramesh
Greenhorn

Joined: Jan 31, 2005
Posts: 5
Hi anagha,


If you would like to inform the caller, better to go for exceptions. But since you said you will be handling the decision, which implies internal to the component or application, I suggest you to use the ValueObject method.


regards,
Vishnu
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Is the client going to DO anything different based on all these booleans? If it's only going to display different messages, why make the client interpret them at all. Maybe just return one authenticated boolean and a message.

Even that might be too much.

Any of that sound interesting?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: designing a authentication mechanism
 
Similar Threads
Make Active n Inactive button using JavaScript
Verifying the db file
JSF form population
Page not refreshing dynamic content.
Getting old values when fetching data in Hibernate