jsessionid causing pain

[Mark Lundquist <ml...@wrinkledog.com>]

Hi,

I'm using Cocoon 2.1.5 w/ Jetty 4.2.15.

I have an unusual application of the Cocoon authentication framework.  
The site we're developing is sort of a satellite of the client's main 
site.  The user authenticates at the main site, after which the link to 
our site contains embedded id and password strings in the URI.  My 
Cocoon authentication resource extracts the id and password from the 
request — there's no login page on our site.  If authentication fails, 
I need to redirect the user back to the "mother ship".

My problem is that the redirect back to the main site's login page is 
issued with the ';jsessionid=......" crap appended to the URI, so their 
server cannot match it.  Bummer!  Is there any way I can somehow kill 
the session if authentication failed?  Or another way to lose this 
jsessionid thing in this case, at least?

Thanks,
mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: AW: jsessionid causing pain

[Mark Lundquist <ml...@wrinkledog.com>]

On May 10, 2004, at 11:54 AM, Nils wrote:

> could you post an excerpt of your sitemap, please`?

Sure... sounds like you'd like to do something similar...?
here ya go...
~mark


       <!--
	++ the authentication resource
	-->
       <map:match pattern="authenticate">
         <map:act type="request">
           <map:call function="authenticate">
             <map:parameter name="resource" 
value="{request-param:resource}" />
           </map:call>
         </map:act>
       </map:match>
      <! -- invoked by flowscript above... -->
       <map:match pattern="authenticate.result">
         <map:generate type="jx" src="authentication/result.jx" />
         <map:serialize type="xml" />
       </map:match>

       <!--
         ++ Our set-up of the Cocoon auth fw is a little unique here... 
we don't
         ++ have our own login page at all, instead we only
         ++ authenticate based on info ("?login:password") embedded in 
the
         ++ link from the XXXX end-user page.  If the user is not
         ++ authenticated, we redirect them back to the XXXX  login
         ++ page.  The whole idea is to avoid the need for
         ++ double-authentication (once at XXXX, and once here).  We
         ++ therefore need for our authentication resource to be 
requested for
         ++ any unauthenticated access to a protected resource, without
         ++ displaying any login form.  Hence, we invoke the auth-login 
action
         ++ here, in the redirect-to resource of the authentication 
handler,
         ++ whereas normally it would be invoked from the handler of a 
login
         ++ form.
         -->
       <map:match pattern="login">
         <map:act type="auth-login">
           <map:parameter name="handler" value="auth-agent" />
           <map:parameter name="parameter_resource" 
value="{request-param:resource}" />
           <map:redirect-to uri="{request-param:resource}" />
         </map:act>
         <map:redirect-to uri="https://xxxxxxxxxx/login.pl" />
       </map:match>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

AW: jsessionid causing pain

[Nils <co...@lolili.de>]

could you post an excerpt of your sitemap, please`?

> -----Ursprüngliche Nachricht-----
> Von: Mark Lundquist [mailto:ml@wrinkledog.com] 
> Gesendet: Montag, 10. Mai 2004 20:40
> An: users@cocoon.apache.org
> Betreff: jsessionid causing pain
> 
> 
> Hi,
> 
> I'm using Cocoon 2.1.5 w/ Jetty 4.2.15.
> 
> I have an unusual application of the Cocoon authentication 
> framework.  
> The site we're developing is sort of a satellite of the client's main 
> site.  The user authenticates at the main site, after which 
> the link to 
> our site contains embedded id and password strings in the URI.  My 
> Cocoon authentication resource extracts the id and password from the 
> request — there's no login page on our site.  If 
> authentication fails, 
> I need to redirect the user back to the "mother ship".
> 
> My problem is that the redirect back to the main site's login page is 
> issued with the ';jsessionid=......" crap appended to the 
> URI, so their 
> server cannot match it.  Bummer!  Is there any way I can somehow kill 
> the session if authentication failed?  Or another way to lose this 
> jsessionid thing in this case, at least?
> 
> Thanks,
> mark
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org