Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------

Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------

Hey Jonatan, 

I'll be honest, I'm not totally sure what token_login is for - but there are other mechanisms that might be useful here. 
token_login - is possibly something related to older functionality like CDSSO or ECSSO? And might not be related to API/Authorization headers. 

Are you using OAuth Auth? or something? We have dedicated template pages for this - that you could set to behave as you expect? 
Also - you might not be aware of the content type aware responses, 
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-content-aware-server-responses

So, when you get a bad token, we could send a 401 or a 403 - depending on your deployment. You can have it respond differently according to your client? 

------------------------------
Philip Nye
IBM
Gold Coast

Original Message:
Sent: Wed August 14, 2024 03:02 AM
From: Jonatan Wålegård
Subject: local-response-redirect-uri and follow-redirects-for

Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------

@Philip Nye Thanks, it's what I want. However I couldn't get it to work. I created a new file called login.401.json and put it under /errors/C/ and /management/C/. When I send the failed request, ISVA is still redirecting the request to the EAI.

If the failed (unauthenticated) request contains application/json I want WebSEAL to be clever enough to just respond with a 401 rather than redirecting the request to the EAI. 

Hey Jonatan, 

I'll be honest, I'm not totally sure what token_login is for - but there are other mechanisms that might be useful here. 
token_login - is possibly something related to older functionality like CDSSO or ECSSO? And might not be related to API/Authorization headers. 

Are you using OAuth Auth? or something? We have dedicated template pages for this - that you could set to behave as you expect? 
Also - you might not be aware of the content type aware responses, 
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-content-aware-server-responses

So, when you get a bad token, we could send a 401 or a 403 - depending on your deployment. You can have it respond differently according to your client? 

------------------------------
Philip Nye
IBM
Gold Coast

Original Message:
Sent: Wed August 14, 2024 03:02 AM
From: Jonatan Wålegård
Subject: local-response-redirect-uri and follow-redirects-for

Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------

I don't believe you'll be able to use LRR and that Login template changes at the same time. 
They are essentially competing functions.

LRR says "Don't use your template page" but go somewhere - which can do it for me. 

Your EAI could also be smart enough to handle the request in the same fashion though.

You could potentially add a macro to the redirect to have it behave in a particular way - not sure if you get a good 'error' text though for a bad Authz Token. 

Try turning on some of these macros (they will be put in the query string on the LRR Redirect) - see if you get anything good. (Just comment out the lines) 

macro = TAM_OP
#macro = USERNAME
#macro = METHOD
#macro = URL
#macro = REFERER
#macro = HOSTNAME
#macro = AUTHNLEVEL
#macro = FAILREASON
#macro = PROTOCOL
#macro = ERROR_CODE
#macro = ERROR_TEXT
#macro = ERROR_URL
#macro = OLDSESSION
#macro = EXPIRE_SECS
#macro = HTTPHDR{<name>}
#macro = CREDATTR{<name>}
#macro = SECONDARY_BASE

Alternatively, you can not use LRR - and use the login.html to do a JavaScript redirect to your EAI, and then have a login.401.json to behave as you expect. 

Or - you can start into the world of Lua - to give you the desired behavior under specific conditions. 
For example, when you see ISVA redirecting to the EAI - you could add additional logic - like if the Content type is JSON, to rewrite the response to a 401. 

Generally speaking - when you start to get into niche use cases - I often encourage separating your API calls from your Web/Cookie based calls through separate Reverse Proxy's, this is what will give you easier control - and prevent these overlapping behaviors. 

@Philip Nye Thanks, it's what I want. However I couldn't get it to work. I created a new file called login.401.json and put it under /errors/C/ and /management/C/. When I send the failed request, ISVA is still redirecting the request to the EAI.

If the failed (unauthenticated) request contains application/json I want WebSEAL to be clever enough to just respond with a 401 rather than redirecting the request to the EAI. 

Hey Jonatan, 

I'll be honest, I'm not totally sure what token_login is for - but there are other mechanisms that might be useful here. 
token_login - is possibly something related to older functionality like CDSSO or ECSSO? And might not be related to API/Authorization headers. 

Are you using OAuth Auth? or something? We have dedicated template pages for this - that you could set to behave as you expect? 
Also - you might not be aware of the content type aware responses, 
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-content-aware-server-responses

So, when you get a bad token, we could send a 401 or a 403 - depending on your deployment. You can have it respond differently according to your client? 

------------------------------
Philip Nye
IBM
Gold Coast

Original Message:
Sent: Wed August 14, 2024 03:02 AM
From: Jonatan Wålegård
Subject: local-response-redirect-uri and follow-redirects-for

Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------

There is one other trick - that might be useful, you can turn on HTML redirects. Which gives you one extra template page to use - even with LRR. 

#--------------------------
# HTML REDIRECTION
#--------------------------
# Enable this option to use the redirect template response file to handle
# redirections.
#
# WebSEAL typically provides a 302 redirection in cases such as when a user
# successfully authenticates. Many AJAX applications do not behave correctly
# when this happens as any HTTP fragments are lost.
#
# Enabling this configuration item will cause WebSEAL to send the redirect
# template response file instead of a 302.  The redirect template response file
# is defined by the html-redirect configuration entry within this stanza.
#
# This configuration item cannot be used in conjunction with
# login-redirect-page.
enable-html-redirect = no

By default WebSEAL sends a 302 response when a redirect is required, along with the 38cf0421.html error page. This error page can be customized with different response codes for different response types if a 302 response is not desired.

Not sure how badly you want the LRR to follow redirects/hide the redirect though. Since you'll likely lose any benefits of that function. 

I don't believe you'll be able to use LRR and that Login template changes at the same time. 
They are essentially competing functions.

LRR says "Don't use your template page" but go somewhere - which can do it for me. 

Your EAI could also be smart enough to handle the request in the same fashion though.

You could potentially add a macro to the redirect to have it behave in a particular way - not sure if you get a good 'error' text though for a bad Authz Token. 

Try turning on some of these macros (they will be put in the query string on the LRR Redirect) - see if you get anything good. (Just comment out the lines) 

macro = TAM_OP
#macro = USERNAME
#macro = METHOD
#macro = URL
#macro = REFERER
#macro = HOSTNAME
#macro = AUTHNLEVEL
#macro = FAILREASON
#macro = PROTOCOL
#macro = ERROR_CODE
#macro = ERROR_TEXT
#macro = ERROR_URL
#macro = OLDSESSION
#macro = EXPIRE_SECS
#macro = HTTPHDR{<name>}
#macro = CREDATTR{<name>}
#macro = SECONDARY_BASE

Alternatively, you can not use LRR - and use the login.html to do a JavaScript redirect to your EAI, and then have a login.401.json to behave as you expect. 

Or - you can start into the world of Lua - to give you the desired behavior under specific conditions. 
For example, when you see ISVA redirecting to the EAI - you could add additional logic - like if the Content type is JSON, to rewrite the response to a 401. 

Generally speaking - when you start to get into niche use cases - I often encourage separating your API calls from your Web/Cookie based calls through separate Reverse Proxy's, this is what will give you easier control - and prevent these overlapping behaviors. 

@Philip Nye Thanks, it's what I want. However I couldn't get it to work. I created a new file called login.401.json and put it under /errors/C/ and /management/C/. When I send the failed request, ISVA is still redirecting the request to the EAI.

If the failed (unauthenticated) request contains application/json I want WebSEAL to be clever enough to just respond with a 401 rather than redirecting the request to the EAI. 

Hey Jonatan, 

I'll be honest, I'm not totally sure what token_login is for - but there are other mechanisms that might be useful here. 
token_login - is possibly something related to older functionality like CDSSO or ECSSO? And might not be related to API/Authorization headers. 

Are you using OAuth Auth? or something? We have dedicated template pages for this - that you could set to behave as you expect? 
Also - you might not be aware of the content type aware responses, 
https://www.ibm.com/docs/en/sva/10.0.8?topic=configuration-content-aware-server-responses

So, when you get a bad token, we could send a 401 or a 403 - depending on your deployment. You can have it respond differently according to your client? 

------------------------------
Philip Nye
IBM
Gold Coast

Original Message:
Sent: Wed August 14, 2024 03:02 AM
From: Jonatan Wålegård
Subject: local-response-redirect-uri and follow-redirects-for

Hi,

Based on this article ISAM Selective use of Local Response Redirect

1. I have added another URL for [token_login] but when I send an invalid token in the authorization header, it defaults to the URL specified in the [login] instead. Perhaps I have misunderstood the meaning of token_login. I also couldn't find an explanation in the documentation, can anyone clarify?

2. I have added follow-redirects-for = !LRR! under the [server] stanza but the 302 is still being presented to the browser, that is to say, it had no impact at all. Could it be that another setting is blocking it from triggering?

Thanks

------------------------------
Jonatan Wålegård
------------------------------