Re: Passing User ID and Password in Applet

Wim, Pete and all

CORRECTION!!!!!

Sorry about what was written.  It sounded like I did not like Wim's 
implementation but meant I did not like the implementation of the portal 
article as the thread mentions and gives reasons why.

Sorry.  It seems I need to go back and learn how to write in my native 
language :-)

Kenneth

Kenneth Pouncey wrote:

> Hello Pete
>
> Pete Helgren wrote:
>
>> I had posted some of this about two years ago when I first started 
>> working with the 5250 applet.  The problems that I had (and still 
>> have) have to do with the passing of UserID and password in the clear 
>> when I start an applet session.  Gaurav posted some code that has a 
>> servlet that talks to the applet and passes the password back to it.  
>> I think I can follow the approach but wanted to know if anyone else 
>> had solved this problem in a different way.
>
>
> I do not remember this post for having the applet talk with a 
> servlet.  That would take a modification of the applet code correct?  
> What would be the key to pass to the servlet to obtain the 
> information?  Actually asking what the flow is for the communication.  
> It actually sounds quite neat and if you have an example could you 
> post it again.
>
>>
>> We have an HTML based menuing system that runs on the iSeries (under 
>> an Apache web server).  The user logs in via an HTML login prompt and 
>> then the menu(s) are generated from there.  Some of the menu items 
>> are HTML based but some are 5250 apps and we launch them using 
>> tn5250j in an applet.  We generate the HTML that launches the applet 
>> on the fly using a template but so far we have had to pass the 
>> password in the clear, not a good solution.  
>
>
> What about doing the signin within the code first using a ProtocolBean 
> or SessionBean?  When the applet is served it would already be on the 
> display that would like.  Kind of like the Portal conversation that 
> Wim and I were having a couple of days ago.  That is bascially what he 
> was doing.  Not sure I like the solution he suggests as I think there 
> are more elegant ways to do this within the code base.  With the 
> SessionBean you can set this information before doing the connect via 
> the setter methods.  Including the program and library to start with.
>
> Look in the list archives for the Portal conversation.
>
>> So, if you have any ideas that we could use to start the applet 
>> without passing the password in the clear, I'd like to hear about it.
>>
>> We also have a need to end the application gracefully when the users 
>> are done running the 5250 application.  Right now, we display a 
>> message that says "Click the Exit link to end the program" and the 
>> user has to click the link to end the session.  What I would like to 
>> do is have the applet close when the 5250 application has ended 
>> automatically.  I am not sure how to accomplish this since the 5250 
>> session would have to "tell" the applet to close....
>
>
> I am not to sure how to handle this scenario of closing an applet but 
> what you could do is attach a scan listener to the session object and 
> then trap that code in your listener.  Am not clear on the applet 
> closing part though as to what exactly it should do.  Within your 
> scanner listener you could then call another servlet to close the 
> session or redirect you to another page.
>
> It would actually take a modification to the host application though 
> to do this.
>
> Basically it would be a screen that starts with #! in the first 
> position with the command to parse after it.  All the code is there to 
> see how it works in scan() method.  I think I posted something on this 
> last week and that is how Wim does this within his application.  Well 
> actually from what I understand he passes whole processes to the scan 
> listener to run custom objects but the concept is the same.  Again 
> unfortunately a modification of the host system to call the new 
> display screen at the end though.  That is the only way the 
> applet/emulator would know when it should close down.
>
>>
>> I'd appreciate anyone's idea as to how to solve these two issues as 
>> simply as possible.
>> Thanks,
>
>
> Hopefully the above helps.  Am sure Wim could answer some more 
> questions on this as that was what we came up with when he was asking 
> about this.  I had some very basic code implementing this idea in the 
> emulator but Wim and his team went way further with it.  Actually 
> works like a charm.
>
> Regards
>
> Kenneth
>
>>
>> Pete Helgren
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Tn5250j-general mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tn5250j-general
>>
>> .
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Tn5250j-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tn5250j-general
>
> .
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click