I'm using ServiceStack 3.9.70 on IIS8 - when POSTing invalid user creds to the default authentication provider service at "auth/credentials" a "401 unauthorized" response is returned as expected along with the browser (both chrome and firefox) prompting for "Authentication Required".
This is all in the context of an angularjs app and I'm handling the 401 response accordingly however the browser prompt is quite annoying and I want it gone. How can I prevent the browser from prompting for credentials when a 401 response is returned from my ServiceStack authentication service?
Thanks!
Sometimes a good night sleep makes all the difference. I solved this by simply disabling basic authentication. I made an entry in my web.config but the same change can be made directly in IIS under the site's "Authentication" feature. Now the 401 response can be handled accordingly by my angular app without the browser throwing a prompt.
<system.webServer>
<security>
<authentication>
<basicAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
i think the 401 response is appropriate for standard http status code protocol , similar to the 403 Forbidden response.
if you want to avoid the credential handshake and save bandwidth you can include in the HEAD request on the same resource at each RESTful request you sending.
Related
Our application is protected with OpenAM web agent. We are encountering a situation where after the OpenAM is sending a post request with HTTP_REMOTELOGIN and Set cookie.But as response Iplanetdirectorypro cookie is getting expired. The issue came when the domain of our web site got changed from a.x--> a.y. Things are working perfectly for old URL domain.
Same configuration for the new domain is working on pre production and when the changes where done to Production, the web page after authentication from SSO is not properly loading due to the fact the OpenAM cookie is getting expired.
In the browser we can see the warning as "A cookie associated with a cross-site resource was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032."
The issue is persisting on all web browsers.
We tried various things in IIS such as enabling CORS, disabling secure cookie setting but we had no luck.
So the question is whether OpenAM cookie managed somewhere in IIS which needs to be configured specific to the new domain.
Can anyone help !
I'm getting this error when trying to hit a service from postman but not through advanced rest client.Intially, thought it is due to some web cache layer on the server or some postman cookies but when I'm accessing it fails but another colleague access the same service it becomes successful.I'm using desktop application Postman.we are using AJP connections on JBoss server and max packet size and body size are set to max. can anyone guide me?
It may caused by large request due to many cookies attached to your request, You need to delete the cookies manually, which can be done which chrome settings:
chrome://settings/content/cookies Then go to "See all cookies and site data"
If you are using Native Postman use its Cookie manager
Native Postman app there is "Cookie manager"
I am running a sample program on SOAP web service on ecplise with jboss.
In Web Service Tester, when I gave the wsdl url and clicked "invoke" button, i am getting the following error:
com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 401: Unauthorized
please help
I got to similar problem. Several things can go wrong.
1) If you are testing something, the system performing the testing could have blacklisted or non whitelisted IP.
2) If there is a mysql backend handling the request you might need to update the previleges for the mysql.
Is it possible that the XPages REST component returns 401 HTTP status code after invalid authentication? Now it returns 200 and the server login page.
My NSF app is used only as a REST service interface to serve the backend application data.
It may be possible to do this using an "Override Session Authentication" web rule in the Directory. I believe that that's intended for cordoning off parts of a server like this that shouldn't use session authentication.
Starting with Domino 9.0.1 FP10 there is now a notes.ini configuration that forces Domino to return HTTP 401 Unauthorized when serving the login page:
DOMINO_FORCE401_WITH_HTML_LOGIN_PAGE=1
I have a web application running on Weblogic. The HTTPS URL to this application is https://localhost:7002/MyApp.
Whenever I am changing the URL in the address bar to http://localhost:7002/MyApp, it automatically redirects to the original HTTPS based URL.
My requirement is to take the user to some kind of custom error page, if they request the HTTP URL. For example, http://localhost:7002/MyApp should redirect to https://localhost:7002/MyApp/error.jsp.
Is this redirection possible to configure in Weblogic?
You mentioned that your https URL is:
https://localhost:7002/MyApp
And assuming that your http URL is:
http://localhost:7001/MyApp
When you say you change the https URL in browser to:
http://localhost:7002/MyApp
This is in-correct. If you provide such a URL, WLS will accept the request on secure port 7002 but will fail to identify the protocol (it expected https but you gave http). Instead of a redirection, you would get some error in browser and definitely following error in WLS logs:
<May XX, 2013 XX:XX:17 PM IST> <Warning> <Security> <BEA-090475> <Plaintext data for protocol HTTP was received from peer
XXXXXXXXXXXXXX - 192.169.0.100 instead of an SSL handshake.>
I assume you are changing the URL to:
http://localhost:7001/MyApp
Please correct/update your issue description.
Now onto your requirement, it seems nearly impossible to do this via WLS configuration.
As a workaround, you can create a servlet filter and call isSecure on ServletRequest to determine whether the request was made using secure protocol or not. If you find it was not, then you can redirect to some custom page. And you would also need to disable this automatic redirection to https that you have reported for your application.
Ref: http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#isSecure%28%29