response.setHeader problem

[Arvind]

Here is where am stuck...

SiteMinder protects all our application.
Siteminder sets request headers for user id.
//applications use the following code snipped to get at user id
//request.getHeader("userid")

When we start development on local workstations...we have had
problems..so i though of writing a dummy servlet that all local
machines could hit first; which would populate the response header
with userid=1234 so that the subsequent hits can make use of
absolutely the same code.

i had the following in my dummy servlet....

resp.setHeader("SM_USER","xxxxxxxx");
resp.addHeader("SM","eeeee");
resp.addIntHeader("abcd",1);

Cookie c = new Cookie("SM","1234444");
resp.addCookie(c);


out of all of the above; when i dump all the request headers....the
only thing request header i get is the cookie - > "Name = cookie and
val=SM=1234444"

help is greatly appreciated !
Arvind

 

[Anton Spaans]

Here is where am stuck...

SiteMinder protects all our application.
Siteminder sets request headers for user id.
//applications use the following code snipped to get at user id
//request.getHeader("userid")

When we start development on local workstations...we have had
problems..so i though of writing a dummy servlet that all local
machines could hit first; which would populate the response header
with userid=1234 so that the subsequent hits can make use of
absolutely the same code.

i had the following in my dummy servlet....

resp.setHeader("SM_USER","xxxxxxxx");
resp.addHeader("SM","eeeee");
resp.addIntHeader("abcd",1);

Cookie c = new Cookie("SM","1234444");
resp.addCookie(c);


out of all of the above; when i dump all the request headers....the
only thing request header i get is the cookie - > "Name = cookie and
val=SM=1234444"

help is greatly appreciated !
Arvind

Hi.
- Request headers are only sent by the browser (and/or proxy). They are not
determined by previous calls to response.setHeader(...).
- Response headers, sent by the server, are only read by the browser (and/or
proxy). You can not re-query them from the request-headers.

Example:
Request 1 does: reponse.setHeader("my_parm1", "val1");
Request 2 does: request.getHeader("my_parm1") : This one *will* return null.

If you want to send values from one request to the next one, either use
cookies or use (hidden) input fields (<input type="hidden" .../> or other
visible input fields.)

-- Anton.

 

[Arvind]

Hi.
- Request headers are only sent by the browser (and/or proxy). They are not
determined by previous calls to response.setHeader(...).
- Response headers, sent by the server, are only read by the browser (and/or
proxy). You can not re-query them from the request-headers.

Example:
Request 1 does: reponse.setHeader("my_parm1", "val1");
Request 2 does: request.getHeader("my_parm1") : This one *will* return null.

If you want to send values from one request to the next one, either use
cookies or use (hidden) input fields (<input type="hidden" .../> or other
visible input fields.)

-- Anton.

Hi Anton,

Thanks - However, you see, all the applications that are protected by
siteminder; seem to consistenly pass parameters via the header to the
servlet....

if what you say is true - does that mean the Siteminder application
manages to intercept every query - add something to the request header
to consistently make the variables like user id available to the
consuming/rec servlets ?

And all servlet specs seem to point that you can(implicitly) set
custom headers for the browser to send it back ? (& HTTP rfc does not
seem to contain it ?)

flip side of the question is - what is the fun of setting custom
headers that browser is not gonna understand anyway and you want be
able to access it subsequently either ?


Arvind

 

[Anton Spaans]

"Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in

Hi Anton,

Thanks - However, you see, all the applications that are protected by
siteminder; seem to consistenly pass parameters via the header to the
servlet....

if what you say is true - does that mean the Siteminder application
manages to intercept every query - add something to the request header
to consistently make the variables like user id available to the
consuming/rec servlets ?

And all servlet specs seem to point that you can(implicitly) set
custom headers for the browser to send it back ? (& HTTP rfc does not
seem to contain it ?)

flip side of the question is - what is the fun of setting custom
headers that browser is not gonna understand anyway and you want be
able to access it subsequently either ?


Arvind

Exactly, 'custom' response-headers are only read by the recipient. If the
direct recipient is your browser, then it would not understand any of the
custom response-headers but its own. But, you may have an applet/plugin
running in your browser that issues requests expecting responses with custom
headers or you may have another client running or there is some other client
in the middle (either a proxy/firewall on the server side or some firewall
on the client site, for example) that understands these 'custom'
response-headers.

I don't know SiteMinder, but it could catch response-headers, store them in
some kind of SiteMinder session, and add them to the next *request* as
request-headers...

 

[Arvind]

Thanks Anton, i basically had to accept the custom request headers'
dont get passed back and forth...

spoke with couple of folks about SiteMinder - and you were on the mark
- SiteMinder populates a cookie - and *every* request gets intercepted
by the SiteMinder web agent (sits typically on the http server) and
uses the cookie to retr (from in-memory store) user attributes and
adds them to the request header and forward the same to the
application....

immediately, i realized Servlet Filters as a prime candidate - and
with couple of "googling" - got the exact behaviour replicated now on
local host.

@others, who migh come searching for the implementation...
Basically wrote a filter - which (based on some mechanism- simply say
global variable) checks whether User id is already set...if not -
"forward" them to login screen...if the upi is already set in the
global variable - create a custom request obbject - which basically
implmenets HttpServlet & is constructed with regular request object -
except that "getHeader" & getHeaderNames method (whatever in your
case) behave in a fashion to recognise request for user id - and
instead of request.getHeader - it would return the global variable...

other ways of doing it ?????

thanks a ton !
Arvind

 

[Anton Spaans]

Thanks Anton, i basically had to accept the custom request headers'
dont get passed back and forth...

spoke with couple of folks about SiteMinder - and you were on the mark
- SiteMinder populates a cookie - and *every* request gets intercepted
by the SiteMinder web agent (sits typically on the http server) and
uses the cookie to retr (from in-memory store) user attributes and
adds them to the request header and forward the same to the
application....

immediately, i realized Servlet Filters as a prime candidate - and
with couple of "googling" - got the exact behaviour replicated now on
local host.

@others, who migh come searching for the implementation...
Basically wrote a filter - which (based on some mechanism- simply say
global variable) checks whether User id is already set...if not -
"forward" them to login screen...if the upi is already set in the
global variable - create a custom request obbject - which basically
implmenets HttpServlet & is constructed with regular request object -
except that "getHeader" & getHeaderNames method (whatever in your
case) behave in a fashion to recognise request for user id - and
instead of request.getHeader - it would return the global variable...

other ways of doing it ?????

thanks a ton !
Arvind

"Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in

Hi Arvind,

This'll work (as far as i can tell), but it is not 'elegant'
I'd suggest you use the HttpSession object (request.getSession(true), is the
call, i think) to do what you want. This will be much more portable and
'cleaner'.

-- Anton.

 

[Andrew Thompson]

This'll work (as far as i can tell), but it is not 'elegant'

I would argue that the 130 or
so lines quoted was less elegant..

Plese make use of your delete key to
remove lines that do not require repeating..
<http://www.physci.org/kbd.jsp?key=del>

 

[Arvind]

Anton,

Thanks...

If you are talking about maintaining the user id via session - i
fully agree - but this was more of 'breaking the ice' - i'd now have
some folks work on it - to make it more extensible and also work with
multiple users simultaneously....

But as i said, the point was to get the headers going the way it does
on the servers....that works -

Arvind