Chaining Session hooks? (resurrected)

Jan Vilhuber JVilhuber at absolute.com
Tue Jun 6 09:34:44 EDT 2017


I no longer have the original thread, but here's the message I'm replying to:

----------
List:       shibboleth-users
Subject:    Re: Chaining Session hooks?
From:       Peter Schober <peter.schober () univie ! ac ! at>
Date:       2017-04-20 14:29:26
Message-ID: 20170420142926.GV14492 () aco ! net
* Cantor, Scott <cantor.2 at osu.edu> [2017-04-20 16:24]:
> > I don't want to call into the SAME hook twice. I want to call into hookA and
> > then hookB (migrating legacy apps into the modern world is the bane of my
> > existence).
> 
> I believe both of us understood that.

The suggestion was to rewrite your hook to become UberHook, that
performs both tasks you envisaged splitting into hookA and hookB.
-peter
-------------

I guess I still misunderstood how aggressively sessionhook does loop detection. I had run a test that showed I COULD actually run hookA and have it redirect to hookB (except I didn't use a 302, but for testing had hookA display variables I could look at and then display a link to hookB to simulate the call to hookB, which worked when clicked on! apparently that wasn't a valid test, though). What I'm seeing now is: SP does a 302 redirect to hookA. hookA does a 302 redirect to hookB. The intention was to have hookB redirect to 'return'. But what I see instead is a 301 redirect, which I'm pretty certain comes from the SP, which redirects back to hookB. This results in a 404 for hookB.

What I have is basically two apps, that really work as one (one legacy, one new), each trying to do their own session management (so I can eventually tease them apart), and there's network appliances on the path to one of the apps that need to be called at least once to set up load-balancing etc etc (I'll spare you the gory details). Due to the network-path issues (out of my control, sadly) I can't have a superHook, and have it do HookA and HookB (the call to hookB has to pass through the network path). I also can't (easily; seriously) make the harder call (hookB) run first and call the easier hookA (there's dependencies).

Any other way I can accomplish this? Any ideas? Can I turn off the aggressive loop-detection?
Jan



More information about the users mailing list