topic Change in StoredProcess Webapp with regards to passwords in Administration and Deployment

Change in StoredProcess Webapp with regards to passwords

Kurt_Bremser — Mon, 12 Mar 2018 15:16:29 GMT

Dear all,

after some stumbling blocks (see my other post in the admin&deploy community), I managed to update our server installation (AIX) from 9.4 M2 to 9.4 M5.

We now face the problem that URLs of the type

http://servername/SASStoredProcess/do?_program=xxxxxx&param=yyyyy&_user=zzzzz&_password={SAS001}ppppppppppp

do not work, although

AllowEncodedPassword

has been set to true (actually always was) in the Advanced tab of the Configuration Manager/SAS Application Infrastructure/Stored Process Web App 9.4 object in SAS MC

Omitting _password= lets the URL work.

The SASServer_1 was restarted with tcruntime-ctl.sh restart after verifying the metadata entry.

Re: Change in StoredProcess Webapp with regards to passwords

jklaverstijn — Tue, 13 Mar 2018 21:05:34 GMT

Hi Kurt,

What is the response you get from this URL that makes you decide it does't work? That would maybe help determining where the problem lies. Any relevant lines from the server.log you'd like to share with us?

Regards,

- Jan.

Re: Change in StoredProcess Webapp with regards to passwords

jklaverstijn — Tue, 13 Mar 2018 21:14:11 GMT

Could you try with the password URL-encoded so at least the curly braces around SAS001 are replaced with %7B and %7D? The actual password may or may not need encoding depending on its value.

Hope this helps,

- Jan.

Re: Change in StoredProcess Webapp with regards to passwords 9.4 M5

Kurt_Bremser — Wed, 14 Mar 2018 06:30:59 GMT

Bingo!

That's it!

Somewhere on the way from M2 to M5 the webserver must have changed so that it does not accept the curly braces natively any longer. Replacing them with the encoded values did the trick.

Re: Change in StoredProcess Webapp with regards to passwords 9.4 M5

Kurt_Bremser — Wed, 14 Mar 2018 06:35:15 GMT

@jklaverstijn wrote:

Hi Kurt,

What is the response you get from this URL that makes you decide it does't work? That would maybe help determining where the problem lies. Any relevant lines from the server.log you'd like to share with us?

Regards,

- Jan.

Just to answer this one:

Literally nothing happened. Just a blank tab in the browser.

In the server logs I could see the request in the access log of the webserver, but the web application server had a strange entry like this:

xxx.xxx.xxx.xxx - - [13/Mar/2018:20:04:18 +0100] "GET null null" 400 -

so it looks like the webserver sent an empty request to the webapp server.