The pzPostData value is a pointer to an internal map that contains data from an earlier HTTP POST request that caused a HTTP 303 redirect.
If a HTTP POST was done using: https://xxxxx/prweb/PRServlet the application will send a HTTP 303 redirect so that the AccessGroup Hash is added to the URL and processing can occur in the proper context. To preserve the HTTP POST data we store the data in a map and provide the pzPostData parameter and value so the resulting GET request doesn't have data loss.
Browser follows the redirect using the location header as a HTTP GET request. We internally use the pzPostData pointer to make sure that the processing occurs with the same data from the original HTTP POST.
When I use the mashup with single sign on url or without single sign on url, access group hash is added in the mashp url, not sure what is it significance. Sometimes even without this access group hash also same code works when try with direct url.
my questions are.
1. which part of code generate access group hash in the mashup url?
2. Let us assume, operator id is configured with two access groups abc and xyz..
when user login through mashup , want to have default access group abc
when user login through composite portal (without mash up) , want to have default access group xyz.
is it achievable through access group Hash?
Are we able tomanually configure access group hash in the mashup?
We are trying to launch a harness using Pega Mashup . After all the SSO authentication and LDAP authorization. The HTML form is rendered blank . However if I do "View Source" , I see the Pega Form's Content loaded .
I see the following error in when I do the View Source . But we do have the JS enabled on the browser . what could be the reason? We are using Pega 7.3.1.
Thank you very much for the explaination on this, it is what I suspected but nice to be sure. I have a case where it seems not working very well as my posted data on the first request is not available in my authentication activity called on the redirected url. Can you explain us how we could debut this functionnality ? add some logs, see the data associated with this postdata code ?
Also seems really strange that it is temporary issue, we got it few months ago for some time then it started working again without any change in the authentication activity and now again it is not working without any delivery from one day working and the next day not working, I am wondering what could impact this functionnality.