File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "designing a authentication mechanism" Watch "designing a authentication mechanism" New topic

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 ,
Vishnu Ramesh

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.

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:
subject: designing a authentication mechanism
It's not a secret anymore!