I have ran a SQL script to update the UserPreferences.UseLegacyUI to 0 for all of the users in our 2018 R1 system but, the users are still getting the classic UI when they log into the system. Any thoughts on why this might be? We're trying to avoid every user having to change their setting in their profile.
EDIT: Users are having to switch to the modern UI every time they log in. Is there a cookie involved?
Try using the UserPreference graph to change that value, that's how it's used in 'Main.aspx.cs'. Sometimes there's code in event handlers that needs to be executed too:
PX.SM.SMAccessPersonalMaint prefGraph = PX.Data.PXGraph.CreateInstance<PX.SM.SMAccessPersonalMaint>();
PX.SM.UserPreferences prefs = prefGraph.UserPrefs.SelectSingle() ?? prefGraph.UserPrefs.Insert();
prefs.UseLegacyUI = false;
prefGraph.UserPrefs.Update(prefs);
prefGraph.Persist();
There was an HTTP redirect set in IIS on both the web site and the web application that was causing this. I suspect this was a hold over from the 5.3 installation but, not sure. Removing the redirect from the web application and removing the "/main.aspx" from the web site redirect cured this issue.
Related
I have tried everything. I configured Windows Server 2019 according to Microsoft documentation and I successfully deployed a .NET 5 web application to the IIS.
I can get to the login page. I can even get to the forgot password page and they show themselves fine. However when I try to do any action (send the forgot password link or login to the page) I get a "Bad Request" from the server. I haven't found a way to explain why.
I have tried several, and I mean several things found Googling around but nothing helps. This include disabling https within the .NET Core application, trying to get a detailed error page using the app.UseDeveloperExceptionPage(); instruction inside Startup, etc etc but nothing works. I always receive this page trying to execute any action:
If someone could help or point me into the right direction, I will really, REALLY appreciate it.
Thank you
PD: In case it has anything to do with the problem, the error, at least the two that I can reproduce (because I can't even log in), happens, I think (maybe don't) when redirecting to another page in Microsoft Identity.
EDIT: code was asked by one of you. Thank you.
As you see, there's nothing specific in the forgot password screen for my application. This is scaffold code from Microsoft Identity. I even edited it and just let one line of code inside it, which is the default return code anyway as follow:
public async Task<IActionResult> OnPostAsync()
{
return RedirectToPage("./ForgotPasswordConfirmation");
}
As you can see, there's nothing special with that code. Here's the html that calls it, again, is a scaffold of Microsoft Identity with little to no changes (by little, I mean, maybe some CSS and a new value of view data):
But then again, forgot password page actually shows and seems well in the front end, but immediately I try to enter my email and click enter in this page, (also, just a scaffold of Microsoft Identity):
Nothing happens. I receive the bad request. There's NO magic nor custom code here. Something silly is going on.
EDIT II: YES, locally it works perfectly. The strange behavior happens only when deployed to IIS.
EDIT III: I coded and enabled logging in my .NET Core APP and wrote that to a file, and I think I finally got, at least the error (not the reason yet):
But why?? Cookies are enabled in the server browser without avail, same issue. Someone has a better idea than disabling anti forgery rules to login and forgot password pages?
Thank you
For some reason, when I deployed the first version of my app into IIS, I thought it was a good idea to just browse it from the IIS link. Of course, in a new mounted Windows Server 2019, IE is still the default browser. I connected directly to the IP of my web app via VPN, but used Chrome this time. Guess what? All problems disappeared. Yes, it's a bad idea to try to use a modern framework like .NET Core Identity with IE.
I'm developing a SharePoint Timer Job to geocode some lists of addresses held on our SharePoint site.
I'm using code based on this MSDN sample to do the actual Geocoding request.
The problem I get is that when I call the service from SharePoint 2010 (running locally) I get a 401 unauthorised error in return.
Interestingly, I have also created a small winforms application which does the same thing (but without SharePoint/IIS) using the same code which works perfectly.
I'm setting the credentials the same way on both apps as follows:
request.Proxy.Credentials = CredentialCache.DefaultCredentials;
I'm an enterprise user and I'm using the same key on both apps - but one works and one doesn't - any ideas why this might be? Is it something i need to set in IIS perhaps?
I tried setting Pipelined = false on the request which was a suggestion I read about on but that didn't seem to work.
Any suggestions gratefully accepted.
Looks like you solved it by changing the identity of the application pool.
The other way to do it is to say that the web service call should be made using the identity of the user that sent the request to SharePoint. To do that try something like:
using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
{
WCFTestService.ServiceClient myService = new WCFTestService.ServiceClient();
Response.Write(myService.GetData(123) + "<br/>");
myService.Close();
}
I have my site hosted on IIS hosting. Site has feature that needs calling WCF service and then return result. The issue is that site is processing calling to WCF service another web site calling is freezing and not return content fast (this is just static content). I setup two chrome instances with different imacros' scripts, which one is calling page that requests wcf service and another one page is just static content. So here I can just see that when first page that requests wcf services freezes, another one page also freezes and when first is released the second is too.
Do I need reconfigure something in my Web.Config or do should I do something else to get possible to get static content immediately.
I think that there are two seperate problems here:
Why does the page that uses the WCF service freeze
Why does the static content page freeze
On the page that calls the WCF service a common problem is that the WCF client is not closed. By default there are 10 WCF connections with a timeout of 1 min. The first 10 calls go fine (say they execute i 2 secs), then the 11th call comes, there are no free wcf connections it must therefore wait 58 secs for a connection to timeout and become available.
On why your static page freezes. It could be that your client only allows one connection to the site, the request for the static page is not sent untill the request for the page with the wcf services is complete.
You should check the IIS logs to see how must time IIS is reporting that the request is taking.
I would say that this is a threading issue. This MSDN KB article has some suggestions on how to tune your ASP.NET threading behavior:
http://support.microsoft.com/kb/821268
From article - ...you can tune the following parameters in your Machine.config file to best fit your situation:
maxWorkerThreads
minWorkerThreads
maxIoThreads
minFreeThreads
minLocalRequestFreeThreads
maxconnection
executionTimeout
To successfully resolve these problems, do the following:
Limit the number of ASP.NET requests that can execute at the same time to approximately 12 per CPU.
Permit Web service callbacks to freely use threads in the ThreadPool.
Select an appropriate value for the maxconnections parameter. Base your selection on the number of IP addresses and AppDomains that are used.
etc...
Consider such scenario: when you make a request to IIS your app changes, deletes or creates some file outside of App_Data folder. This often tends to be a log file which is mistakenly was put at bin folder of the app. The file system changes lead to AppDomain reloading by IIS as it thinks that app was changed, hence the experienced delay. This may or may not apply to your issue, but it is a common mistake in ASP.NET apps.
Well, maybe there is no problem...
It may be just the browser's same domain simultaneous requests limit.
Until the browser not finished the request to the first page (the WCF page), it won't send the request to the second page (the static).
Try this:
Use different browsers for each page (for example chrome/firefox).
Or open the second page in chrome in incognito window (Ctrl + Shift + N).
Or try to access each page from different computer.
You could try to use AppFabric and see what is wrong with your WCF services http://msdn.microsoft.com/en-us/windowsserver/ee695849
Is there any method to tell from javascript if the browser has "enhanced security configuration" enabled?
I keep running into problems with certain controls not working from within dynamically loaded content. This only happens with browsers running on Windows Server 2003/2008 systems - even when I add the server to the "trusted" zone.
Maybe somebody has already develoepd a method for accomplishing this task?
Thanks in advance
Instead of testing for IE ESC directly, we can test for its effects.
I found that with ESC enabled the onclick events of dynamically added content would not fire.
So I am testing those events directly.
var IEESCEnabled = true;
var testButton = $("<button style=\"display: none;\" onclick=\"IEESCEnabled = false; alert('No problems here.');\">Test IE ESC</button>");
testButton.click();
if (IEESCEnabled) {
alert("We have a problem.");
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
In my application a test like this forwards the user to a page explaining their issue. It is accompanied by a noscript element to check that they have JavaScript running at all.
I don't think it's possible, and if it still is, than that's a bug that might sooner or later be fixed.
One of the main points of this "extra security" was for the client to have it but not to be detected by the servers, thus leaving them no way to know when to try to circumvent it and when not.
Isn't javascript disabled when using enhanced security configuration?
Then if you only want to display a message to the user, simply display a message in normal html and hide it with javascript so only users without javascript will see it. If you need to handle it on the server side (e.g. outputting a differerent version of your website) simply include javascript to redirect users to your javascript enabled version. Users without javascript will remain on the non-js page.
If only scriptable activex are disabled, the same method applies, simply insert a activeX and try to "script" it, if it fails you can redirect, show a message etc.
The above of course doesn't detect enhanced security configuration per se, but the symptons that occur when it is enabled. So it probably wouldn't be able to distinguish between users with using enhanced security configuration and users that simply have JS/ActiveX disabled or use a Browser that doesn't support scripting in the first place.
I think you can look for SV1 in the user agent string.
What are the best practices for updating a web application in IIS?
The first page you see when you visit our application is a login page.
What I want to achieve is that visitors be redirected to a page stating that the application is being updated. And for users with an admin role being able to login successfully (to check whether everything is working properly)
In web.config we keep track of wheter the application is being updated (updating = [true|false] and then on the authentication_event:
if (updating)
{
if (User.IsInRole("admin"))
{
redirect to main web app...
}
else
{
redirect to web being updated page....
}
}
else
{
redirect to main web app..
}
Any advise will be appreciated immensely..
I test everything locally, then I use the built in app_offline.html file on production server.
When this file is present it will be served to clients, in meantime I am uploading new content. When done, renaming app_offline.html to something different and the new app starts.
instead of doing it via web.config, you should be saving the updating flag in some other xml file or database, as each time you update your web.config file, your application restarts, thus invalidating current application variables, caches, etc etc
apart from that, you got the other logic right. but avoid touching the web.config as far as possible - i personally only save the connection string in the web.config as that hardly changes
but rest of the key value pairs which change often, i have them saved in sql database table. so that way i never ever have to do an application restart unless my connection string changes :-)
Looks like you pretty much have it figured out.
if (WebConfigurationManager.AppSettings["updating"]=="true")
if (User.IsInRole("admin"))
Response.Redirect("~/Main.aspx");
else
Response.Redirect("~/Updating.aspx");
else
Response.Redirect("~/Main.aspx");