I have created an site on Umbraco 7.1.6 it was working perfect in Visual studio 2012; when I deployed it to my hosting space I found a problem that it redirects me to login screen again and again just after some seconds. I have set keep user login to true and increased timeout but no improvement.
When I searched for that problem I found some links:
https://github.com/umbraco/Umbraco-CMS/compare/release-7.1.6...7.2.0
http://issues.umbraco.org/issue/U4-3845
https://github.com/Umbraco/Umbraco-CMS/commit/c936aaa51753862914591b753f7f2d7be7749cf7
First link provide me file but I do not know how to updated my current site.
In console I am getting an error.
GET http://example.com/umbraco/backoffice/UmbracoApi/Authentication/GetRemainingTimeoutSeconds 401 (Unauthorized) angular.min.js:106(anonymous function) angular.min.js:106o angular.min.js:102g angular.min.js:100i angular.min.js:79i angular.min.js:79(anonymous function) angular.min.js:80e.$eval angular.min.js:92e.$digest angular.min.js:90e.$apply angular.min.js:92safeApply umbraco.services.js:58(anonymous function) umbraco.services.js:6773(anonymous function) angular.min.js:108e angular.min.js:31(anonymous function)
I just experienced the exact same symptoms. A site ran just fine locally, using IIS Express, worked fine when deployed to Azure WebSites, but when I ran on a Windows Shared Hosting environment, the back office session would timeout somewhere between a couple seconds and a couple minutes.
I'd get a pop-up authentication window often but not always on the GetRemainingTimeoutSeconds url.
I filed a ticket, and the provider was able to replicate the issue. They said the site was running in full trust.
After enabling 32 bit application support - the issue is resolved.
Thanks to everyone, especially to #Morten Oc who commented.
It's properly something on the hosting. Have you tried other Umbraco installations on hosterpk? Also, try to set the login time (in webconfig) to 0.
I found out a solution that it was due to hosting environment (permissions), I deployed on client's hosting and it works perfectly.
Additionally if you do not have full trust hosting then it would not be able to maintain its session, you would have to configure session to managed in database.
For more info how to configure please refer to this post:
https://www.saotn.org/configure-sqlserver-sessionstate-for-umbraco/
Related
We suddenly started seeing this "Could not create SSL/TLS secure channel" error.
Our website does a simple POST to another server to a HTTPS URL
This suddenly stopped working
Nothing has changed (Windows Updates, our updates, server settings) to cause suspicion. That we know of, or can remember.
We can navigate to the posted URL just fine.
We have other websites that also do this same POST to that same server and they continue to work. Everything is using TLS 1.0 and the target server has not changed anything recently. Nobody has turned off TLS 1.0 on either side.
This issue is discussed in many other stackoverflow postings, so to research systematically we made a clone of the website on the same server. Just copied its code (compiled code folders) and set up another virtual host in the same IIS.
The POST operation from the clone works! Same server, same code, same IIS. So we can't even reproduce it on the exact same setup. The copy is working but the original is throwing this error.
So finally the question:
Does the fact that the copied website can POST successfully give anybody any insight into what may have happened?
Could some IIS settings on the original site been changed? The only thing different is they are two virtual hosts on the same server.
Windows Server 2012R2, IIS 8.5, ASP.NET/C#.
I found the solution here:
https://social.technet.microsoft.com/Forums/en-US/9dfb4d09-8096-40c9-ac75-1e23f75417c9/frequent-event-id-36888-windows-schannel-errors-in-the-event-viewer?forum=W8ITProPreRel
The causes can be many, apparently, even Windows updates. Still seems odd that it would happen (consistently) on one website and not on its clone (also consistently).
The specific steps to fix were:
In Group Policy Editor (run: gpedit.msc), went to Computer Configuration > Administrative Templates > System > Distributed COM > Application Compatibility and enabled "allow local activation security check exemptions"
I have very strange problem. I use ZfcUser as authentication module. I made a lot of projects on lot of different environments using ZF3 and ZfcUser module. I have nevere experienced such kind of problem which I will explain bellow. In my current project I cant login into system on production server. I succesfuly log from local env, or other test environments.
I try to investigate whats going on. I went to login page on production, entered my credentials and system redirects me to home page. No errors, no warnings... notihnig. But I was not logged in. I check the identity from the framework (identity()) - it was null. I thought that may be it is server issue with the php sessions. I checked the sessions on server. It appears that the problem was not there.
The framework succesfully stored the data it needs in sessions. I found the Zend_Auth key, the identity key and the value for logged user. It seems that with php sessions everything is OK.
I am powerless and cant even think about what is going on here and where is the problem. No errors are thrown. I trace the execution of code on local and production environment. Everything is same. The frameworks seems to work properly. But the IDENTITY is allways null
Found the problem.
So, the site was runing under a subdomain. Let say sub.domain.tld. This site is different from main domain which is domain.tld. In the programm code, the favicon of application was requested form the domain.tld not from the sub.domain.tld.
As a result when you hit the http://sub.domain.tld the browser stores two PHPSESSID cookies. One under sub.domain and another under domain.tld which couses Chrome to messed up
Interesting is that, Firefox and IE didnt messed with the sessions and the site was working porperly. I dont say that Crhome is guilty. Obviously the programm code was cousing the problem. But Chrome recognize that one domain is sub domain of the other
Thats why, when I was trying to run project on different environments as local setup or different domain e.g. test.different-domain.tld, ther were again two PHPSESSID cookies set, but in this time Chrome didnt messed up with the sessions becouse test.different-domain.tld is not recognized as subdomain of domain.tld
Very small and silly mistake, but cousing big problems
I just created a webform that is hosted in my Azure subscription. I set it up with authenication via my works Azure directory for authenticating users. In debug this works fine and I am able to login with my work credentials and then view the website via local host.
I have published this to my Azure and it says it is running and working fine. So when I try to connect to the website it continuously redirects me to the localhost resulting in an error.
I have checked the web config.
Here is the google network chain of events when it occurs.
I am really lost as to what is wrong and what I need to do to fix this so any help would be greatly appreciated. I'm sorry I can't offer more but I don't even know what is wrong to begin with or where to look. Is there some setting in Azure that I need to add the website too?
I have solved this issue. Since it was such a pain I will keep this up as I couldn't find any answers on this. It was actually quite simple.
You have two options. The one I did and which worked was changing the publish profile as below:
Add the domain where the authentication is occurring. So if you have your web app hosted by a different azure account that which is authenticating the users, use the one that is authenticating.
This will create two versions of your app on the site one for local host and one for the actual site.
The second option(I have not tried this but it should work) is to go to the Azure account where you are authenticating the users and go to applications and then configure. Change the APP URL from local host to the url you are trying to get to.
Here is an excellent link that explains how to do this clearly.
Click this link for detailed explanation
I also had this issue and took these steps to resolve
navigate to the app registration in AAD
Open the manifest
Change the ReplyUrl to the url of the app (e.g. http://appname.azurewebsites.net)
Then I got the error
Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.
Next I cleared all cookies from the browser, and this changed the error to just
Bad Request
So I went back to that ReplyUrl and changed it to https://appname.azurewebsites.net/.auth/login/aad/callback and now it appears to work.
Note I also had to make sure I didn't have the site open in any other tabs before it started working
I had this issue when I switched an app from our company Azure over to a customer's Azure. In my case I'd forgotten to update the ida:ClientId, ida:AADInstance and ida:TenantId, which then meant that the value I'd set for ida:PostLogoutRedirectUri was ignored (I think) and instead my app redirected to localhost.
Once I changed those ida values to the values from the app settings and subscriptions settings on our customer's Azure it all worked as expected.
It took a while to track down all the values in Azure portal as they are all called something different, or aren't named at all:
ClientId can be found at Azure Active Directory > App Registrations > YourAppName. It's called 'Application ID' in Azure
Domain can be found on Azure Active Directory > Overview. It's currently in the top left in the format somename.onmicrosoft.com
TenantId this is the Azure AD instance ID, get that from Azure Active Directory > Properties and then it's called 'Directory ID'
I spent a lot of time trying to work out where the localhost port that was being redirected to was in the code, but it simply isn't there as far as I can see, so I have no idea how Azure was choosing what localhost address to redirect to!
You need to set another parameter in configuration that is replyUrl and assign to your web app, other wise it takes the url from which it was originated.
I was able to fix this by changing my Startup.Auth.cs file redirectUri from "https://localhost:44316/" to https://myapp.com/
Got a site still in dev that uses ServiceStack's Open ID implementation to sign in users. It's been working fine all this time, suddenly today morning Google's OpenID login started failing, Facebook still authenticates fine. No error is thrown, just redirects back to the default url with this appended to it:
#f=Unknown
On my localhost it works flawlessly, both Google and FB login ok, only in production does it fail. I have tried quite a lot:
Re-verified each and every file in my asp.net bin folder compared with local and production, no difference.
Re-routed the production domain name to my localhost (in the hosts file), in hopes to step through the creation of the session. No luck, still signs in flawlessly.
Connected via remote desktop to the server and tried logging in on it as localhost, fails. (yea, WTH?).
Is there a way I can get a log of what is going on as the authentication is happening? or does anyone have an idea of what could be the issue?
On a side note: I recently changed dns settings for the domain name and moved it to this new server, but that was around 3-4 days ago, and it's been working fine all this time, until today morning. Also noticed that a reverse DNS lookup on my IP resolves to a different domain, investigating that right now.
UPDATE
This issue reared it's ugly head again this morning. I'm not sure what could be causing it but I suspect windows automatic time synchronization to be somehow throwing things off. I'm turning it off and going to keep an eye on things to see if it returns. Also, this issue seems to throw my SSL settings into chaos, i have to manually reset IIS's SSL bindings in order for things to work, even WebDeply is affected. Very strange.
UPDATE 2
Issue happened again today. I'm now suspecting it's somehow related to IIS's web deploy feature cause it happened immediately after I published my site. Also now realised that I don't need to reboot, a simple iisreset seems to fix it. Will keep monitoring.
FINAL UPDATE
I finally found the culprit. Time. My virtual server was gaining time very fast and every few days it would be ahead of most other servers and so the authentication would fail. The limit seemed to be around 3-5minutes, within that range, the authentication works okay. More than that, it fails. To get around it, simply enable time syncing and it should not re-appear.
You can check your production server clock. The OpenID request synch with the internet time in order to validate the request. If the clock is off or it was off for a while just reboot and the problem will be solved.
If you navigate to http://www.website.com/ you will see the IIS7 welcome screen.
If you navigate to http://www.website.com/?abcd123 (or any random querystring) you will see the correct site.
If you navigate to http://www.website.com/default.asp (which is also set as the default document) you will see the correct site.
Can anyone explain to me why this is happening?
What is even more strange is that if I stop the web publishing service on the server, http://www.website.com/ still responds with the IIS7 welcome screen, but http://www.website.com/?randomquerystring gets a request timeout error (as it should).
I have check and rechecked:
Default document (default.asp only)
Custom error pages (disabled)
Output caching (turned off)
Cleared local browser cache
Tried the various URLs on multiple machines in 3 different locations and via proxify.com
The site is running in its own AppPool in integrated mode, .Net 2.0.
Any help would be really appreciated.
Problem has been fixed.
This was due to a 'corrupted cache store' on the firewall of my hosting company. It was not an IIS issue.
Rory , did you restart your application pool as well as the site. please restart once and also check for the authentication .