Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I'm really just posting this so at least there's one relevant hit if anyone googles for it.
We use query parameters in links from our main website that point to portal pages that are protected by login. E.g. https://someportal.whateverdomain.com/buyaproduct/?productid=12345
The portal is configured to use Azure AD B2C for sign-in / sign-up and if a user is not yet authenticated then the portal redirects the user to B2C to login because the buyaproduct page is only accessible to signed-in users. On completion of sign-in, the user should be at the buyaproduct page looking at product 12345.
Up until about the start of February, this was all working finely and the productid was passed through the B2C login (in the state property, if I recall correctly).
However, it seems a portal update (to 9.3.ish) in early February broke this and the parameter is now lost through the B2C process. [I can see it's a portal and not a B2C problem because checking in the Chrome debugger I can see there is a redirect to a portal-based ExternalLogin URL first and the parameter is contained in that but incorrectly URL encoded.]
Anyway: couldn't find a workaround, it's been raised with Microsoft Support and we await some useful progress.
Not certain yet if it was anything to do with *my* support call, but this was fixed in the environments I care about by the (scheduled) portal update that Microsoft performed last night.
We're now at version 220.127.116.11 (according to the /_services/about url) whereas the problem version was 18.104.22.168.
In the meantime I had created a brand new trial portal that did *not* appear to exhibit the problem - the version on that was 22.214.171.124, though that has also been updated to 126.96.36.199 overnight.
Yes, it is a known issue. If you upgrade your portal to the latest, the issue will be fixed.
@Mohamed Mohran: Don't suppose you've got any kind of reference number or link for that bug, have you? Support (first-line) are telling me there's no particular mention of the (now fixed) issue...
(I was hoping to gain some understanding for next time...)
Business Applications communities