Portal URL does not lead to the specific record

[indyanin]

Hello experts,

I'm facing very strange behavior related to portal URL handling by my Self-Support Portal. I'm almost sure it used to work correctly but now it doesn't. 

When I want to share a portal link that leads straight to a case record like so:

 <my-site-name>.powerappsportals.com/support/edit-case/?id=673937f7-075f-eb11-a81c-000d3abe331f

When the person that receives this link is already logged in and has the right to access that record it works as expected.

The problem becomes apparent when a person is not logged in and after clicking a link, Portal redirects that user to the login page, updating the URL to:

<my-site-name>.powerappsportals.com/SignIn?ReturnUrl=/support/edit-case/&id=673937f7-075f-eb11-a81c-000d3abe331f 

That part after ReturnUrl is what tells the portal where to go after successful login, but it is wrongly constructed as it should be a question mark (?) instead of the ampersand (&) colored red in the URL above.

So when I logged in, the request goes straight to <my-site-name>.powerappsportals.com/support/edit-case/  leaving out the id of my record (the part that begins with an ampersand).

When I manually update ampersand to question mark and hit enter and then log in, it takes me to my record, otherwise, it obviously tells me that the record was not found as the id was cut out of the URL. 

Please someone could help me out with this problem? Could you confirm that this behavior is present on your portals?

Thanks,

Konrad

[justinburch]

Hi @indyanin,

That's interesting.. The Return URL is appending instead of converting. It should look like this:

<my-site-name>.powerappsportals.com/SignIn?ReturnUrl=%2Fsupport%2Fedit-case%2F%3Fid%3D673937f7-075f-eb11-a81c-000d3abe331f

I'll try to test this later if someone else doesn't figured out, but my initial thoughts are leaning toward needing a ticket as the routing doesn't appear to be working.

[indyanin]

@justinburch thanks for the quick reply. I would be super grateful if you could test this out and let me know how is it working in your env. I really wonder what caused this strange behaviour but for sure something behind the scenes over which I do not have control.  I also would like to know if I'm the only one with that particular problem. 

I will definitely create a ticket when you confirm that yours is working correctly.

[Pranjali · Accepted solution]

Hey Konrad,

I do know for a fact that this was working before.
Let's also do a test.

Try accessing <portalurl>/support/ from your browser [assuming you have the access control rules, you will be asked to sign in]
click on sign in
enter your creds or use SSO to login

--> verify if you are redirected to <portalurl>/support/ after authentication

I tried the scenario you have described but am unable to repro it. If you are still facing an issue, please raise a support incident with the Portals team at Microsoft. It could be particular to your configuration.

Cheers!

Pranjali

[Fubar]

I don't have a customer self-service portal to try it at the moment but in my custom portal it is encoding the return url correctly 

[indyanin]

@Pranjali with /support/ it works as expected, the problem starts when the id is added as a query parameter. as @justinburch described, after adding ReturnUrl query parameter it should encode Uri the latter part but instead, it appends URL with id.

I requested a ticket with Micorosft, will notify you what was going on if they find a fix.

[jplfin]

Hello @indyanin 

Do you have any news on this topic? We are facing the same issue.

Thanks,

JP

[indyanin]

@jplfin nice timing. I've received the final answer from MS just yesterday after over a week of battling and trying to make a point. It wasn't an easy task as they couldn't replicate the issue, then that said that I would stick to OOB functionality and don't restrict the path of the cases, but after my further explanation they dug deeper and at the end admitted that this is a bug on their side, that they discover thanks to my report, and as a representative from MS has said:

"The Product Team was able to replicate the same issue on a vanilla environment on the Portal version 9.3.1.2. With this, a work item was created to resolve this, but currently we do not have an ETA for the deployment. "

For now, it seems that there is not much we can do, I only hope that they will give the issue a high priority.

Regards,

Konrad

[justinburch]

Hi @indyanin & @jplfin,

Though it's not ideal, one thing you can do for now is setup the permissions so that they don't automatically redirect. Then you can use Liquid to identify if the user is not logged in, and show a custom message with a link to a login with an appropriately encrypted return URL.

Note that I'm going off of some very old memory here (can spin up a trial later to confirm some things), so YMMV.

1. Ensure that Entity Permissions for the Case forms are Yes
2. Ensure there are no Web Page or Website Access Control Rules with "Restrict Read" for the Case Web Page or any of it's parental hierarchy
   • These first two steps should mean that when users not logged in will instead see a "You don't have permissions to view this" message instead of a redirect to a login - test here, if still logging in then this solution may not work
3. In your Case Web template (or if the Page template uses an .aspx page instead, this code may need to go into the Header template.. I can't recall), add something along the lines of the below code (would be best under the Entity Form tag anywhere, as it will show after the "permissions" message)
4. OPTIONALLY: You could instead add your own auto-redirect.. just change the HTML message into a JS on document ready for window href assignment. Potentially a poorer user experience with the hops and possible loops.

I hope this helps,

Justin

{%- unless user -%}
<p>It looks like you haven't logged in. Please <a href="/SignIn?returnUrl={{ request.path_and_query | url_escape }}">click here to login</a> first.</p>
{%- endunless -%}​

[indyanin]

@justinburch @jplfin @Pranjali the problem has been silently fixed! Thanks, MS for the quick reaction!