LJ, Actually.... I would bet that the problem lies with the "Portal" design vs "ARS license restrictions".
I suggest that [EMAIL PROTECTED] needs to read up on ARS and the use of Load Balancers to understand the implications of the Mid-Tier/ARS and the Users (AKA: client) IP address restrictions. My guess (and I could be wrong) is that the Portal is not "sticky" and that the end user is not connecting to ARS via the same "Portal" web server all of the time. ( It is kind of a "sessionID" thing, but more physical than that for the license restrictions with ARS.) One way to "solve it" would be to have the Portal always route traffic to Host "X" when talking to ARS. Then any Login/Logout would be coming from that host. You may have to do some fancy content rewriting to make it all work, but I think that might make it possible to have the user bounce around in the Portal application (from web server to web server) and have all "ARS" traffic only be handled by a dedicated "Portal to ARS" host too. (But it is likely to much effort to be worth it IMHO.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Mon, Apr 14, 2008 at 9:46 AM, LJ Longwing <[EMAIL PROTECTED]> wrote: > ** > > The problem as I understand it is that each browser window has its own > session ID, and your login from your browser is tied to that session ID, so > when you call the logout from browser window 2, it's a different session ID, > and as such, has nothing to do. I believe what you need to do is figure out > a way, prolly Java Script, to communicate between your multiple browser > windows (should be possible) and have each of them perform the logout, > because you aren't exactly sure which one did the login, I think that would > solve your problem. > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Prashant Patil > Sent: Monday, April 14, 2008 2:08 AM > To: arslist@ARSLIST.ORG > > Subject: Re: Explicitly Invalidate Remedy Session > > > > ** Dear All, > > Let me explain the problem again: > > > > We have a corporate portal. The user logs into the corporate portal. He > clicks on a link for Remedy and we pass the username and password in the url > and the user accesses remedy to register trouble tickets etc. Hence the > login is transparent to users. The portal is based on frames and remedy > opens in the content frame. > > When the user performs a portal logout in this window where Remedy is open > in a frame, we call the logout http://<server>/arsys/shared/logoutservlet. > This kills the Remedy session and works perfectly. > > This url works perfectly if the portal logout is being performed from the > main portal window where remedy is in the content frame. However if during > his interaction on the portal if the user clicks on a link which opens > another portal window and he logs out from this second portal window, we > again call the logout servlet. But it does not kill the remedy session in > the main portal window. > > Is there a way where we can kill the user's remedy session from any of the > open portal windows? > > Most clients want the corporate portal to be an access point for all > application and users. Putting Remedy on the portal is a major security > concern for any corporate if we are unable to kill the sessionI appreciate > all the help as there integrations on hold due to this problem. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
