I'm using basic password services. In other scenarios like change password, max retries etc, the smpwservices.fcc does put &USERNAME=username in the query string when it's redirecting to the smpwservices.fcc
However on SMAUTHREASON=20 (ImmedPasswordChange), it doesn't put the username parameter in the query string. The username parameter however is present in the SMTOKEN parameter in a encoded format.
This causes the fcc to ask for the username instead of just the old and new passwords. In the older smpwservicescgi.exe the username was available as a query string. This extra step is undesirable. Is this a known issue?
smpwservices.fcc is designed differently from smpwservicescgi.exe, but the function should be the same.
As an example, you can see USERNAME is not part of SMTOKEN, rather as parameter being passed by itself.
smpwservices.fcc file has at least 10 sections that fits use case "$$smauthreason$$ == 20", if this is customized page, make sure you modify the section that matched with your use case. Or try the default smpwservices.fcc file first.
If default smpwservices.fcc file still asks for entering USERNAME, chances are the variable was lost before it hits smpwservices.fcc during redirect.
I think the user name will be appended to URL by default. I remember having a registry when set the user name is not appended in redirects.
Even though it's supposed to be default, I had to manually add this with value 0 in the sm.registry to get it to work.
this is a known bug in version 12.52 SP1 described in TEC1867466: username in smtoken being encoded .
User upgrade web agent from version 6 to R12.52 and notice user name in smtoken being incorrect encoded during password change process
It should be
Policy server: R12.52SP1
Fix available in R12.52SP1CR1 and later.