Is there anyway currently as it stands to clean up a url so it would only contain the following:
"subdomain.contoso.com" without all the query parameters at the end of it.
Currently on my domain setup I have it as "login.contoso.com" this works fine however it requires all the rest of the following query parameters after the initial domain to be able to work.
Such as "https://login.contoso.com/contoso.onmicrosoft.com/b2c_1a_signup_signin/oauth2/v2.0/authorize?......"
Where we want it as: "https://login.contoso.com"
Is there some guide that points out how we could get this to work without the query parameters being there. As we followed this: https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-domain?pivots=b2c-user-flow
As I understand that you want to have the signup/sign-in URL shortened to domain.com/login. This is only possible if the application handles the signup/sign-in process without using an IDP such as B2C for this purpose. Hence its not possible to customize/hide the parameters within the B2C url, that is how OpenId Connect protocol works.
Reference: https://learn.microsoft.com/en-us/answers/questions/759791/is-it-possible-to-get-a-short-url-for-the-the-sign.html
Related
We have docusign integrated in our platform & all of a sudden we are getting error from DocuSign
"The redirect URI is not registered properly with DocuSign".
We have proper & valid redirect uri configured in the application.
Please Note that exsisting setup is working fine, for newer apps or newer accounts, it is throwing the above-mentioned error Here is the screenshot of the same .
The redirect uri is valid as it's working for other app.
Has something changed at DocuSign end recently?
Update:
As asked, Please find the redirect uri screenshots below (I've masked the host url),
DocuSign Redirect URI configuration - Please note that both URI are same with difference in host url.
Complete Oauth request url
Redirect window
Make sure to compare the URL you see in the browser to the one in the IK. Make sure it's the same IK, in the same env (production vs. developer env is different!). Even a tiny difference between the two URLs will fail this. You need to URL decode the redirecUri from the main URL and then use that by copy/pasting it into the apps and keys page.
Then wait about 1-2 minutes before trying again.
Edit: confirmed that the URLs DO NOT MATCH, and that is the issue. The URLs must match 100% for this to work
Redirect URIs are specific to each integration key (application) and do not get copied over if you make a new integration key. Based on your description it sounds like you have created a new integration key. I would recommend visiting the Apps and Keys page on your DocuSign Admin settings and adding the redirect URI to the new integration key. Here is a support centre article which outlines this including the steps for how to add a new redirect URI
Nothing in this area has changed on DocuSign AFAIK.
Check that the redirect URI specified in your initial OAuth redirect is the exact same as the URI you set in the Integration Key's settings page.
The redirectURI cannot include any dynamic data including query parameters, etc.
You can use the settings tool's Apps and Keys page to delete and then re-add the RedirectURI. Check carefully that it doesn't include any trailing spaces, etc.
After you've made a change via the Apps and Keys pages, wait 5 minutes before attempting to use the Integration Key.
Ensure that you're using the right Apps and Keys page. If your app has passed go-live then:
For the production systems, use the apps and keys page from docusign.net
For the developer (demo) system, use the apps and keys page from demo.docusign.net
I would like your feedback and opinion about using { FrontDoor + Appservices + Authentication + restrict access to FD only }
I do confirm I can set up all of this thanks to all contribution/ forums / blog found on the net. I can use my custom domain which request AD authentication and I am correctly redirect to my appservices (in browser: I see my custom domain name and never see any *.azurefdnet or *azurewebsites.net as expected).
The only problem is that I needed to use a custom domain to make it works. For production purpose it is acceptable to have a custom domain but for dev or test I wonder if we can do it without custom domain by simply keeping original address like *.azurefd.net and *.azurewebsites.net
I struggle to make it works without custom domain. I keep getting “too many redirection” message or ‘403 sites blocked’.
Does anyone success to do it ? My general configuration looks like
My backend is linked with my appservices
Details of my backend is:
I think my problem is with BackendHostHeader but not sure. When i used custom domain for my production it works. But remind i do not want to use custom domain for dev and test.
My route looks like
And finally my appservices is secure to allow frontdoor only
When my user goes to stackoverflo.azurefd.net they get AD authentication which is good but just after i get redirection to xxx.azurewebsites.net with 403 forbidden (which looks normal because of restriction to FD only).
I tried to change the backend host header by replacing by FD value but in this case i get a error with loop redirection.
Is it a feasible scenario without custom domain ?
Regards
PS: i configured Azure ADApp to allow reply url to my FD like stackoverflo.azurefd.net/.auth/login/aad/callback
Yes, you can Restrict the access to website without using Custom Domain.
Goto the Application you want to restrict the access in Azure Portal and select the Networking from left Pane, now click on Access Restrictions.
For complete information you can go through this Microsoft Documentation.
I am using Power Automate for all my API calls to Docusign. I want to be able to capture the authorization code when a user logs into Docusign and then run a flow to get access and refresh tokens.
My flows work when I manually copy the authorization code from a localhost redirection browser session and get the user tokens. I want to be able to redirect to a power automate webhook URL so that when the user logs in, the authorization code is redirected to the power automate webhook trigger where I can grab the authorization code and process it to get user tokens. As an example, I have set up a power automate HTTP webhook trigger and have a URL provided by MS to point to.
https://prod-63.westus.logic.azure.com:443/workflows/887839a887d945919f8a0bb1aa89d2fa/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_3pQLhhEORjAAe3V_IjCPNgBYnHnw2nrdP-oEoIPvyA
I registered this in Docusign as a redirect URL. No configuration or format error was indicated when registering this URL.
When I attempt to log in via a browser session, after entering my credentials, I get a redirection URL not properly registered error.
Are there format or length or other parameters that prohibit the use of this type of URL as a redirection in Docusign?
I'm 90% certain that the URL you are using is dynamic
The sig=_3pQLhhEORjAAe3V_IjCPNgBYnHnw2nrdP-oEoIPvyA
Represent something that will not be the same next time and therefore, my hunch is that it won't do no good to add this type of URL to the list of redirectURI.
You can check to make sure I'm right by looking at the URL you get when you get the error.
If I'm right, then you would have to change your approach to this.
If I'm wrong, then maybe there's some issue with some special character or some other inconsistency and I can ask our engineers to look into this.
It looks to me like you should use the Custom Connector Authorization section of your connector instead of your current approach.
See this doc
I am currently trying out Azure Logic Apps and am now trying to create
a first simple flow that acquires data from an external REST API.
I'm using FRED, a hosted Node-Red instance, to create an REST API end-point.
In FRED you use https://x_y.fred.sensetecnic.com/api/hello to access my mock API (where x_y is my user name).
Accessing "https://x_y.fred.sensetecnic.com/api/hello" in a browser returns the intended data as specified in the Node-Red flow. Same thing goes when accessing
"https://x_y.fred.sensetecnic.com/api/hello" using GET in Postman (then adding two required Headers, required by FRED).
The strange thing is that in my Azure Logic App, I am not able to even save the flow with my URI stated as "https://x_y.fred.sensetecnic.com/api/hello". It states "Enter a valid URI". I enter the headers as was required.
So I can get to the REST API directly from a browser or using Postman, but are not able to access it from within an Azure Logic App.
I test the problem is there is a special characters _ in your URI. You could have a try if you delete _ then it won't state error.
So you coudl Initialize a variable to store your name x_y, then insert the variable in the URI. The flow would be like this. If you don't find the name in Dynamic content, you could use variables('name') this expression to insert it.
With this way the GET method will run correctly.
I have completed all steps properly according to the following sample.
https://github.com/Azure-Samples/active-directory-b2c-dotnet-uwp
I have completed all optional steps as well, but when I test Run Now my SignUpSignIn Policy through azure portal, it keeps loading for a while and then just displays blank white page. I am pretty confident I have configured everything properly my only doubt is the Custom Redirect URI which I have set as following :
com.onmicrosoft.fluensoft.fluennative://redirect/path
fluensoft is my tenant name
fluennative is my native app name
in case of web app/ web api there are clear instructions that redirect uri is an http call, but in case of native custom redirect uri it is very confusing.
Solution :
It was actually a network problem for that specific attempt when I tried the demo, I tried it again the next day and now it works as expected, If you are having the same problem then check your network in developer tools, also check the console just in case.