I have a Relying Party and a provider running with DotNetOpenAuth. The issue is that when the provider has not been accessed in a while it is unloaded from IIS to conserve memory (which is normally a good thing). However, in this case it causes the Relying Party to throw the "No OpenID endpoint found" exception.
I know that IIS can be configured to never unload an application, but that is not an option in this case.
Is there a way to increase the timeout on the relying party to let it wait until the provider "wakes up" and not throw the No OpenId Endpoint Found exception?.
I thought I had it with the "maxAuthenticationTime" property, but I guess this is really a setting for how many minutes in total the authentication round trip should be allowed to take.
Thanks.
Yes, these timeouts can be configured via your web.config file. Below is a snippet, with the defaults which you can raise:
<messaging>
<untrustedWebRequest
timeout="00:00:10"
readWriteTimeout="00:00:01.500"
Full configuration options are documented.
Related
Hi I have deployed wcf service in UAT environment as azure App service. and client calling getting below error -
The message could not be processed. This is most likely because the action '/GetExams' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
On SIT environment and local it works with same configuration. what could be the issue? help appreciated!
According to the error message, you can try to increase the receiveTimeout and inactivityTimeout properties.
If ARR Affinity enabled, that is a client is tied to a specific web worker resulting in unequal distribution of traffic across various worker instances. So, to avoid the unequal distribution of traffic & improve performance we need to the client to be tied to a worker for them to work e.g. Applications using In-Process session. If this is not the case, disable ARR Affinity to achieve a more even load distribution and see if it helps.
I've read about the automatic configuration reload which - according to the docs - also includes security settings. What I could not figure out yet (and did not see any indications for ) is if Artemis also updates Roles etc. when the LDAP auth is active.
Question is: In an ActiveMQ Artemis deployment where OpenLDAP is used for authentication and authorization do I need to take care about updating the roles etc. myself or is this done automatically?
The documentation you cited is related to reloading broker.xml when a change is detected. It isn't really applicable to the LDAP authorization data since that data is in LDAP and not in broker.xml. However, the documentation for the LegacyLDAPSecuritySettingsPlugin is relevant as it discusses the enableListener option:
enableListener. Whether or not to enable a listener that will automatically receive updates made in the LDAP server and update the broker's authorization configuration in real-time. The default value is true.
Since enableListener defaults to true then changes made to your LDAP authorization data should automatically be reflected in the broker.
The listener is an implementation of both javax.naming.event.NamespaceChangeListener and javax.naming.event.ObjectChangeListener and is registered using the javax.naming.event.EventDirContext#addNamingListener(java.lang.String, java.lang.String, javax.naming.directory.SearchControls, javax.naming.event.NamingListener) method.
That said, you may run into ARTEMIS-2671 which will be resolved in the next release (i.e. 2.12.0). It's also possible that your particular LDAP server doesn't actually support this listener functionality. If that's the case then restarting the broker is your only option to reload the LDAP data. Modifying broker.xml won't reload it.
We've been experiencing some deadlocks when working with interconnected ASP.NET WebApis on the same IIS server. We'd like to know if this is somehow an expected behavior, due to hosting all APIs on the same server and same Application Pool, since we have managed to avoid the issue by moving either WebApi to a different pool; or if there's something wrong with our code.
For production, we will probably host the APIs on different server or pools, but still we'd like to understand why this is happening. Our main concern is that, if it's our faulty code, the issue may be reproduced on a larger scale, even if the hosting setup is correct.
We have created a little solution to reproduce the deadlock, hosted in GitHub.
The reproduction steps are as follow:
WebClient executes multiple HTTP request in parallel WebApi1.
WebApi1 executes an HTTP request to WebApi2.
WebApi2 executes an HTTP request to WebApi3.
WebApi3 simply returns a string.
The expected behavior would be that all requests are eventually resolved.
The actual behavior is that, certain requests gets completed, while some others will fail, due to a TaskCancelledException which seems to be due to the requests timing out.
The only article that I was able to find that seems to mention the same issue is from 2014: "Do Not Send ServerXMLHTTP or WinHTTP Requests to the Same Server", I believe that this is the issue we are experiencing, how can we confirm this?
Context
We've been assigned the task to create a centralized authentication server for multiple internal APIs of the company we work at.
We are using IdentityServer3 with reference tokens, so when some API requests a second API using reference tokens, the second API will request the authentication server for token validation which reproduces the issue.
I have added the IdentityServer tag, since this could be a common issue when doing multiple APIs communication and using reference tokens. Sample on GitHub.
Just one observation: you are using HttpClient as a static member for every Controller and according to this HttpClient is not guaranteed to be thread-safe
In IIS, I have an ASP.net web application that makes many behind-the-scenes calls to an IIS-hosted WCF service.
I never had any issues during development. However, since deploying to a few test servers at work, our tester was reporting that some of the calls were seemingly randomly failing. I verified that indeed, some of those behind the scenes webapp->service calls were failing with a "(417) Expectation Failed". Hitting the back-button and attempting the action again always worked.
A common solution I kept seeing online was https://stackoverflow.com/a/7358457/1669011
After adding that to my web config, the error continued to happen, but instead of returning a 417, would end up returning the results of my web.config's applicationInitialization remapManagedRequestsTo page.
I feel like the web.config fix I mentioned above has just allowed my web application to accept the full body of the response rather than failing when it realised it wasn't the wcf response it was expecting.
So if random services in WCF are returning the results of remapped requests that occur during Application Initialization, does that indicate that my WCF services in IIS are constantly totally shutting down?
What might cause my WCF service to randomly be in a state of "application initialization"? I'm hoping this is just a server issue and nothing to do with my application, as this has come out of nowhere and is risking an upcoming deploy.
Thanks for any assistance
My guess would be time (or very serious exceptions).
Specifically, if the server hosting the WCF service is not being hit often enough, it will shut down the application. Follow the instructions here to ensure the WCF site is not being unloaded: How to keep a WCF site online?.
If it's exceptions, you have not provided enough information to diagnose the issue.
I'm having problems with impersonation in WCF. Namely, I'm calling a named pipe service from within ASP.NET with impersonation turned on. This fails (due to permissions on the pipe blocking anyone from the network). So, is there any way I can make the call outside of the impersonation context? I don't need to be impersonating to make this call, but can't see any way of doing this.
Anyone got any ideas?
Thanks
Matt
PS. I need to do this declaratively, through config...
I was lucky enough that the service I needed to disable impersonation on was on an IIS endpoint that no-one else was using, and I could quite happily change the authentication/authorisation parameters in the web.config so that access was granted to anonymous users. Not a fix, but a work around.
As far as I can tell, if I wanted to do this in code, I would wrap my client in a call to WindowsIdentity.Impersonate(IntPtr.Zero), which is apparently the same as calling the Win32 RevertToSelf. I don't know what happens when this context is disposed, though (does the undo re-impersonate the originally impersonated user? Or has the revert stuck?)