I'm developing an app based on the Docusign C# Quickstart.
Its working fine on my development PC (Win 11) in Visual Studio 2019 using IIS Express.
However, when I publish it to IIS (v10) on my development PC it runs and I can authenticate with Docusign just fine (once I got the proper redirect URI registered: https://localhost/ds/callback) but the step that actually sends the envelope is returning the following error in the browser:
This page isn't working right now.
Local host can't handle this request
http error 500
Any help is appreciated. I logged a support ticket with Docusign, but still waiting for a response.
Quickstart is just an app to show you how to use DocuSign APIs.
The redirect after signing is back to localhost, and your app, once ready to be deployed to server, has to be set with a proper URL, at which point you'll need to update the redirect URI to the one based on your server.
The 500 error is coming from your app, not from DocuSign. You need to figure out why your app cannot handle the URL that is set for redirect after signing by DocuSign.
The base API address demo.docusign.net/restapi is used to reach the development/ test platform. The na4.docusign.net/restapi address is one of DocuSign's (many) production platforms.
Remember that, once you have passed the Go-Live process, you have two Client IDs (integration keys) one for the test platform, one for all of the production platforms. Each has its own settings.
Added
The error
This page isn't working right now.
Local host can't handle this request http error 500
Is from IIS. Use IIS logging to see the URL request that is coming in that can't be handled.
To see if it is the redirect from the initial OAuth Authorization Code grant URL, examine the initial URL redirect to account.docusign.com (prod URL).
The redirect contained as a query parameter in the initial OAuth redirect must:
Be correct for your instance of IIS.
Be allowed by your setting for the client ID (integration key) in DocuSign
1, Be properly handled by your IIS and its app.
Related
I've got Azure ServiceFabric web-app (AspNetCore 3) hosted over reverse proxy (NGinx). The app use AzureAD (in company) authentication. I've Registered App for the AD and setup Redirect Urls. After publishing the APP and configuring DNS and reverse proxy I tried to authorize to my app but failed with error
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: '...-...-...-...-...'.
I snifed the request and found that it redirects to the internal IP but not domain name
https://login.microsoftonline.com/aeb55839-c47b-4fea-8d95-912f673fa7ac/oauth2/v2.0/authorize?client_id=.....&redirect_uri=http%3A%2F%2F10.2.0.5%3A44321%2Fsignin-oidc...
It seems that I've looked everywhere but I cannot stil found where I can specify redirect url manually (only CallbackPath).
Does anyone solve the issue?
Update 1.
Add screenshot from Azure Portal
Update 2
Mannually add http://10.2.0.5:44321/signin-oidc to the Redirect Url, get a new exception
AADSTS500117: The reply uri specified in the request isn't using a secure scheme.
I wonder whether I have to make my ASF cluster secured to allow AD Authorization? It seems to me strange due to I want to secure traffic to reverse proxy only.
This error will occur when there is a mismatch of redirect URI being sent in the request to AAD while fetching the token and the one registered with the Application Registration Object in AAD portal.
In App Registration blade of AAD and look for the redirect URI section present under "Authentication" section of the registered application and update the redirection
URL. Please refer to the screenshot below:
update:-
The Reply url you are using in your code is http://10.2.0.5:44321/signin-oidc which is different from reply url defined in Azure AD i.e., https://dev-adm.project-llc.ru/signin-oidc. Please update the reply url in code or in AAD.
I have successfully deployed the virto platform and storefront on to azure.
the CMS content connection string was taken from the platform appsettings and assigned to the storefront CMS connection setting. The Api Hmac App Id and secret keys are assigned as per the documentation.
Platform and storefront are synced in azure with the latest.
however, when the storefront url is entered in the browser, it does not show the storefront, insted the following error occurs.
This page isn’t working our storename.azurewebsites.net is currently unable to handle this request.
HTTP ERROR 500
please advise if anyone encountered such error. Did I miss any other settings?
First of all, that is NOT CMS connection string related issue.
Second, try these:
restart platform app service
restart storefront app service
clear browser cookies / open page in anonymous mode. The url should start with https, not http
wait for 30 seconds as this could be a timeout issue on slower service configurations
Third: set ASPNETCORE_ENVIRONMENT=Development as described in https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-2.2#set-the-environment to get error stacktrace
We have an on-prem asp.net core app that leverage AAD for authentication, the app is setup to run in both:
http://domainserver/app
&
https://domainserver/app
In Azure AD the reply url for the application is setup as
http://domainserver/app/signin-oidc & https://domainserver/app/signin-oidc
When using http url, the sign-in process works fine, however in https mode, we get the following error:
AADSTS50011: The reply address ‘https://domainserver/app/signin-oidc’
does not match the reply addresses configured for the application:
appguid . More details: not specified
The reply https url is setup in AAD for the App exactly as it appears in the error message, so I’m not sure why it says it’s not matching.
One reason I can think of is that the SSL certificate used for https is a local domain signed certificate, and somehow it’s causing the error. But I’m not sure if that’s the case since AAD is just responsible to redirect back to the specified url, should not really care or know about the validity of the SSL.
Here is the image showing the setting url, the redirect url and the error message url matches exactly. You just have to trust me the part that's blocked out are also the same. :)
Anyone got any ideas why this happens?
Protocol matters. Azure AD will treat http://website.com and https://website.com as different reply URLs. However Azure can only let your put in multiple Reply URLs in a same domain. There is a case solution may be helpful to you:
Issue: Using the Azure AD authentication option to sign into the Skype for Business (SfB) Web SDK and you are seeing an AAD error page . The error page should have this message:
"AADSTS50011: The reply address 'https://...' does not match the reply
addresses configured for the application <...>"
Solution:
You need to configure the main domain name where you're hosting your app as a reply URL in the AAD registration for your app and pass it as the redirect_uri when redirecting to AAD to allow the user to sign in.
You should be using code like this to redirect the user to enter her credentials to sign into Azure AD:
var href = 'https://login.microsoftonline.com/common/oauth2/authorize?response_type=token&client_id=';
href += client_id + '&resource=https://webdir.online.lync.com&redirect_uri=' + window.location.href;
window.location.href = href;
Note In the code above that we are using window.location.href as the value of the redirect_uri query parameter in forming the URL of the AAD endpoint where the user will sign in. This parameter tells AAD to redirect the client browser and the access token obtained by signing into AAD back to the page we're currently on - the main app page. However, AAD will only redirect the access token to URLs that are specified as Reply URLs in the app registration in AAD.
Follow these steps to check your configured Reply URLs and add additional ones:
Sign into portal.azure.com with an account that's an administrator on your tenant.
Navigate to Azure Active Directory in the left side bar > App registrations > Your app > All settings > Reply URLS.
Type the domain name where you're hosting your app and click Save.
This solution is from this document.
Update
According to your screenshot, your Reply URI is different:
https://domainserver/app/signin-oidc
is not in your Reply URL list,
in your Reply URL list is
https://domainserver/app/signin-odic
Go to change them as same URL .
I'm using JMeter to load test my web app. I created two HTTP Requests, one visit login page and the other, log into my account. The visit login page HTTP request works fine and returns 302 Found status. JMeter displays the login page and there 0% errors on that page.
However, when I try to login into my account using the POST Data I retrieved from Firebug POST, it doesn't work and returns a 500 status error.
I am having difficulty getting the logging into my account feature to work. I have tried to send a POST request with the following:
1) __RequestVerificationToken
2) languageDropDown (My web app requires it)
3) UserName
4) Password
but I am still getting the error.
I followed this tutorial as it's the only one on ASP.NET MVC web apps...
http://build-failed.blogspot.pt/2012/07/load-testing-aspnet-mvc-part-3-jmeter.html
But I didn't do the feedback form data because I don't need it. Just grab the general concepts and regular expression from that webpage and tried it on my app but it fails.
Why? How do I fix it?
Is it because I have cookies to store session and only unique users can login my web app at one time? I did add a cookie manager though.
BTW, this is on a deployed web application (not localhost).
Some photos, I blocked out all sensitive information (sorry) and some of the token's (Just in case?)
Are you sure you have static authentication token? May it dynamic?
Look at second video that deals with token at 5:37 min to understand how to extract dynamic authentication token.
Exept HTTP Cookie manager, try to add HTTP Cache manager
I'm working with a classic ASP website on a Windows 2003 server. The site requires authentication (configured to use Basic authentication). One page uses ServerXMLHTTP to request data from another page on the same website (same protocol [HTTPS], same host name), using the Open method with the arguments Method, URL, Async, UserName, Password. It's been working correctly for years. When the page that makes the server-side call is requested, the log shows one request, with no user name, for the back-end page that returns a 401 status, and then another request, that includes the user name, that returns a 200. These are followed by the request for the front-end page, with a 200 status.
I've copied the site to a Windows 2008 R2 64-bit server, with apparently the same authentication configuration in IIS. But now no data is received from the back-end page. The log shows TWO consecutive requests for the back-end page with no user name, and BOTH return a 401, and then the request for the front-end page, with a 500 status.
What could the problem be? I've seen discussions of proxycfg, but we aren't using a proxy. I've seen discussions of also setting credentials using Base64, but (a) we don't do that on the old server and (b) I tried it anyway, and it didn't make any difference.
Follow the steps outlined here :- https://stackoverflow.com/a/10762360/1579037
then, check that you can create object instances of the same XML components on the 64 bit server ?