• 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
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

Contradiction in preparing itinerary

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If login is a pre-condition, how come a customer who has not logged in can proceed until he needs to confirm the flights?
 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Daniel CarMichael:
If login is a pre-condition, how come a customer who has not logged in can proceed until he needs to confirm the flights?


That's not the only place in the assigment where I met such a doubtful requirments.
Alex.
 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, its not 100% consistent. What I think is happening here is dealing with 2 types of clients Web and Swing.
While most web systems allow you browse and search as anonymous (which is perfectly ok) they make you log in when you attempt to access URL which is transaction-critical, like in this case.
On the other hand, the Swing client nornally connects to the app server in the beginning with proper credentials by initializing InitialContext object with correct name and password. You could, of course, let your Swing client browse some info and THEN login but that would involve switching JNDI contexts. But this is almost never done.
So the pre-condition to log in comes from having your swing client be logged in at all times, and the alternative flow "not logged in" case comes from the event if the web clients happens to be not-yet logged in.
 
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Gennady, that was helpfull I did not see it from than angle.
 
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gennady Shapiro:

On the other hand, the Swing client nornally connects to the app server in the beginning with proper credentials by initializing InitialContext object with correct name and password. You could, of course, let your Swing client browse some info and THEN login but that would involve switching JNDI contexts. But this is almost never done.


could you please elaborate the statement "but that would involve switching JNDI contexts"? I could not understand why sitching JNDI contexts involved here?
thanks
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In its simples form...when you create an initial context you pass (among others) ID/Password to it as parameters. If your Swing app were to log in as 'anonymous' the system might allow it browse flights but not make reservations. The components that make reservation are protected therefore when you attempt to access them you will get an exception. At this point (or prior to exception) you may want to log in with real credentials and that involves closing your anonymous initial context and creating a new one, this time with good id/password. Thats what i mean by switching context. This technique may work in some cases but you lose session data when you do it, plus it's a very slowest operation.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What about using the addToEnvironment() method. Will the container be able to authenticate at that time??
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gennady,
Wont the same JNDI switching be required in the case of web clients.
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by R Krishnan:
Hi Gennady,
Wont the same JNDI switching be required in the case of web clients.


The answer is two-fold.
1. Not really. Your Web component can run some Fast LaneReaders bypassing the EJB tier. The basic search operations should allow unauthenticated access to this. The Swing app on the other hand must use EJB for anything, therefore must get InitialContext for everything.
So this answers questions posed by FBN spec.
2. More generally, I am not quite sure. Suppose you have 2 Web components: one is configured to run as anonymous and another as 'athenticated.user'. The anonymous component creates the InitialContext with 'anonymous'-security context that is propagated to target beans. Now, the user accesses the protected web resource, gets authenticated thereby changing his security context. At this point the question is whether or not the new security context will be propagated to beans via the established InitialContext. I suspect that No, but if anyone cares to run some tests I'd be interested to hear the results.
[ May 17, 2002: Message edited by: Gennady Shapiro ]
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stop and think about it a little. Or better yet, go to a real airline's web site. Notice you can search for flights, and build an itinerary without logging in.
The use cases state when you *must* be logged in to perform certain tasks -- in fact, they're throwing you a huge hint on how the solution will be architected! See above post about fast-lane readers for more detail.
<soap-box>
I've noticed certain ranch members are always bad-mouthing the part 2 assignment (not the original poster in this thread, mind you), citing conflicting requirements, etc. I can only suggest reading the requirements fully and --heaven forbid-- go through an OOA/OOD process to design a solution.
I know of only -1- problem in the assignment, and the assignment itself calls attention to it!
If anyone has aspirations of becoming a java architect, they'd better get used to having worse requirements than Sun gives you in part 2!!!
</soap-box>
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
SC Johnson
Can you dig it
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic