We have a .Net MVC application that has a controller with a HttpPost Method type and the application is hosted in Azure.
When the application is Idle for 30 minutes and we click on submit button we could see the request being sent to server as HttpGet and there is an exception as unknown method.
I tried looking at app insights traces and there is no issue from the Azure end.
Controller class doesn’t have any method with type HttpGet for the save method.
Where am going wrong here?
May there be not any wrong with you, just use a low tier of Azure WebApp without enable the feature Always on like F1 Free Tier, as the figure below, to enable the Always on feature to avoid your webapp asleep and awake up by a request after idle.
If you can not enable it, please first follow the tips on Azure portal to scale up the tier of your app service plan, then to do it again.
According to the offical document Configure an App Service app in the Azure portal, as the quote and figure below, because Azure will idle your app without Always on enabled to reduce the infrastructure resource cost for no traffic.
Always On: Keep the app loaded even when there's no traffic. It's
required for continuous WebJobs or for WebJobs that are triggered
using a CRON expression.
Related
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
I am using IPN to receive payment notifications in an MVC system I'm working on. After verifying certain bits and pieces, I proceed to update the database with the "subscription" and "payment details" for the particular user. I am using "notify_url" to redirect back to the system and initiate the PaymentNotification method. This was working correctly up until a few days ago, when it all of a sudden just stopped working. First I thought that the database was not being updated due to an issue within the method itself, but then I noticed that the PaymentNotification (IPN) method was not being hit at all.
Some notes:
A test from the paypal developer's page seemed to redirect correctly
into the IPN. Calling the link directly from the browser hits the method also, so it seems to be externally accessible.
I am using NGROK to make the localhost look like it's
running from a live domain. It does not work with either HTTP or
HTTPS. I am also testing on a hosted environment, with sandbox configuration, within an HTTP domain, and it is not working either.
I am debugging the hidden values in the validation form, right
before redirecting to Paypal and all the values, including:
notify_url are correctly populated. This was working but suddenly
stopped.
Some questions:
What could be the reason? Why would it work all throughout the development
stages but suddenly stop working? Of course, I can't afford to have
this stop working on the live environment!
Is this perhaps an issue
with the sandbox environment? Is IPN safe for Live systems? Can someone talk from experience?
Or
is there perhaps a better option I can look into?
I read this article, which
discusses verifying/activating the email address of the sandbox
account. Can anyone indicate what that might be? And whether the same
email addresses being used could have been working but suddenly
stopped? Do they need to be real emails? As the ones that I was using (and were also working) are not tied to real paypal accounts.
As suggested in the comment, even just for testing Paypal in Sandbox mode, since September 2016, TLS 1.2 is required for PayPal IPN processing. In my case, changing the Sandbox testing business and personal emails to real / valid emails, solved my issue with regards to testing locally using NGROK as a secure tunnel to Local host. More so, this should not be a problem when I actually use the HTTPS certificate.
I am using azure AD authentication to authenticate a user in my MVC
application.And I published my application on azure and it is
working fine.
But, when I run my application locally then it Microsoft's login
page comes up and when I enter credentials and click on SignIn
button then it is giving "Sorry, but we’re having trouble signing
you in.We received a bad request."
But the same application is on azure and if I access it from there then it allow me to login.
To create this apllication I follwed link to add azure AD authentication
If you notice the error message, it clearly indicates that you have not configured https://localhost:44320 as one of the reply addresses.
Please go back to application configuration screen in your Azure AD and add https://localhost:44320 as additional reply address. That should take care of this problem.
Add the below to your Web.config. It must be the same port which you have added at the time of Application registration.
<add key="RedirectUri" value="https://localhost:44320/" />
I hit this, it has cost me a lot of time.
I would check firstly that you have the ability in Azure to access third party applications.
In Azure > Users & Groups > User Settings:
You see the first item (Users can allow apps to access their data) - without this checked I believe it wont work.
As you are running your application locally it is not published to Azure, this means that although it may be within the realms of your organisations network, Azure still views it as a third party application.
Be wary setting this to 'Yes'. I understand that there are ways to then create applications that allow you to behave as an Azure super user....
In case anyone else comes across this, here is what happened to me. I had been switching back and forth between environments within Visual Studio (Project >> Properties >> Debug >> Environment Variables). Well, the last time I switched it, I wrote "Develop" instead of "Development" to switch back. This caused .NET Core to grab the wrong appsettings which connected to the wrong AD which did not have my localhost setup on it. It took me an hour to catch what I had done wrong.
This may not be exactly what has happened to you, but do check to make sure you are picking up the Azure AD settings you are expecting if they are in your appsettings. It could be a good point to start at.
I'm certain I've done this a dozen times before, and I can't think what's causing this to fail now, but, I have an MVC web app with its app pool running as a domain account. It connects to a WebAPI app on the same domain which has Windows auth enabled.
I'd like to be able to read the MVC app pool account name using controller.User.Identity.Name on the WebAPI side, but it's coming back empty. I've tried just about everything, including explicitly setting the MVC app to "connect as specific user".
The MVC app is using HttpClient to connect to the API. I've tried passing an HttpClientHandler with UseDefaultCredentials set to true, but that had no effect.
Connecting to the WebAPI methods from my local machine correctly identifies my domain account. Is there something obvious I'm missing?
This was fixed by adding the BackConnectionHostNames key mentioned here:
https://stackoverflow.com/a/10311823/2179408
It wasn't necessary for me to make the legacyImpersonationPolicy and alwaysFlowImpersonationPolicy aspnet.config changes though.
The 401 responses I was receiving threw me off and led me to believe it was an IIS authentication issue.
We are building an online store that is based on Spree and hosted on Heroku. We want to make the checkout as easy as possible so we decided to use PayPal Express Checkout, and Instant Update API to determine the shipping cost.
When we tested the checkout process over HTTP, everything works perfectly - when the user enters his shipping address, PayPal queries our server in the background and obtains the shipping costs.
However when we switched to SSL, the shipping cost just doesn't update and reverts to the default flat-rate. I cannot figure out what is wrong because everything is the same, except this time the app is accessed through HTTPS, i.e. https://myapp.herokuapp.com
I have check the logs and I see that PayPal's server did make the query, but the shipping cost just don't update on PayPal's checkout page.
Any thoughts on what's wrong?
Update:
After further testing, it seems PayPal is not obeying the timeout set in the transaction setup. We added a simple "sleep(x)" to the callback method to artificially induce some delay (by x seconds), and even over normal HTTP, just 1 second delay is enough to caused PayPal to ignore the response.
The max timeout is supposed to be 6 seconds, but in reality it doesn't seem to be the case at all. And couple that with HTTPS (which take longer to establish a connection), it is probably why the callback was failing in the first place.
I have submitted a ticket to PayPal, but I'm not sure if they will respond or do anything about it...
It appears there are many reasons that PayPal could ignore the returned shipping options from the callback.
I'd like to see something on PayPal's site that would keep a history of recent calls to the callback with the returned response and reasons for rejection - somewhat similar to the useful IPN history.
I'm glad you posted your real domain name here because you've pretty much confirmed my suspicions.
I'm pretty convinced the problem is that you have a wildcard SSL (I see your certificate is issued to *.herokuapp.com) and not just an SSL for a single domain.
I am having the same problem with a UCC certificate for www.MicroPedi.com which is a 5 name UCC certificate. PayPal just flat out refuses to even make any calls to it (I have logging and nothing is coming through except when using the sandbox).
To confirm this I have a previous Express checkout implementation that is working just fine (with a single SSL) and I pointed my new application to that old URL and it magically started working again. That is a single name SSL - in fact it's one of those expensive green bar certificates.
I've written directly to PayPal support, but right now the only thing I can think of doing as a workaround is writing some kind of proxy page that will just redirect from the good domain to my UCC domain.