I have a sign up custom policy and we get an intermittent "Bad Request" error after the submit button is clicked. I read somewhere that it could be that the request is too long but I am not sure if this is the same error. When page is refreshed it usually resolves and it goes to the redirect uri and processes successfully. Application insights logs don't have anything. How can I know what the specific cause?
console screen shot
There's an open issue here, where B2C doesn't handle an internal error properly if the page is left open for > ~4 hours. Does this match your scenario?
Related
Display custom error messages on unsucessful login using jaas's j_exception
I have configured tomcat to work with jaas to authenticate my users. I have made use of form based authentication and hence on unsuccessful login i navigate to an error page. Instead of an error page with static message, I wish to display appropriate messages like "Invalid username/password" or "User locked"(i lock the user after 5 unsuccessful attempts) etc from j_exception
How can i achieve this?
I tried googling around the issue and found the following link
http://www.jroller.com/heonkoo/entry/manipulating_login_exception
But this seems like an old post.
I have been struggling with this from a few days. Any help will be greatly appreciated.
JAAS does not provide a standard way to propagate information to the web layer.
You can use a ThreadLocal to store the exception and read it in your error page.
Today, while testing logon and logoff to Spotify via CocoaLibSpotify 2.4.2 (with libspotify-12.1.51-iOS), I have observed errors after entering user and password in SPLoginViewController:
Usually a upsell page is shown, but now there is only an "Access Denied" error shown.
URL causing issues is:
http://libspotify.spotify.s3.amazonaws.com/client-upsell/client-upsell.html?userAgent=xyz&platform=iPhone&locale=de
Any idea whats going on?
We have been getting an error prompt/alert in our XPages application at random times:
"An error occurred while updating some of the page...status:12152" and
"An error occurred while updating some of the page...status:12029"
We can't seem to pin it down to anything. Maybe someone has an idea of what these errors are referring to or maybe how to track it back to something? Thanks.
The HTTP 12152 error usually points to a network connection issue rather than anything specific to the browser or the Domino server.12029 again is down to an inability to make a connection to the server.
It sounds like the network connection is intermittent. I don't know what tools there are to test that, but I would suggest confirming you have a good, stable network connection between PC and server and that it's not getting negatively impacted by a firewall.
It looks like your application is trying to partially refresh content on the screen, and that this partial refresh fails. This can be because the component with that id is no longer found in the component tree.
Have a look at your XPages source code for controls with an id of MainContent and refreshPanel3 and find any partial refreshes on those controls. Check the rendered/loaded property for these controls to see if they are hidden in certain cases. If you do not render a control and want to display it using a partial refresh, you must partially refresh an outer component that contains the non-rendered control.
Use browser's network debug (F12 in Chrome/IE/Firefox w Firebug) to get real server response, it usually contains error page with more info. Failed partial refresh should be the last POST request.
I am running S60 SDK 5th with Eclipse pulsar on win 7.
I have oauth_token using with this Url https://www.linkedin.com/uas/oauth/authorize?oauth_token=. To get that grant access screen by LinkedIn.
I am loading above Url using htmlComponent, and adding HtmlComponent to form and show it.
Occasionally when I click on the "Ok I'll Allow It" button (i.e. after the button has been pressed) I get the following error message.
We’re sorry, there was a problem with your request. Please make sure you have cookies enabled and try again.
But I'm receiving the response with oauth_token, oauth_token_secret, oauth_callback_confirmed = true, xoauth_request_auth_url, oauth_expires_in.
Please help.
My guess is that the error is happening with the callback. Once you click the "OK, I'll allow it" button in the LinkedIn authentication page, the user should be redirected back to your application. Can you run the network for your phone through a laptop system where you can snoop the traffic to see what's happening? I'm not familiar with HTTP snooping capabilities in the Windows 7 system, but there may be some logging you can do to determine what's happening.
My server returns a 403 forbidden error when a user tries to access a resource that they do not have access to. Along with the header the server also writes a small message describing the error.
In Firefox the error message gets displayed nicely and the user knows what's going on.
In Internet Explorer the message is hidden and replaced with the 403 Forbidden standard error page.
Are there any specific rules that allow me to display an error message across all browsers while still setting the status to 403 Forbidden?
Here is the RFC info on this status:
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated. If the
request method was not HEAD and the
server wishes to make public why the
request has not been fulfilled, it
SHOULD describe the reason for the
refusal in the entity. If the server
does not wish to make this information
available to the client, the status
code 404 (Not Found) can be used
instead.
It seems like I should be setting a message but IE just won't display it.
Try making your 403 page larger (i.e. more bytes). Some browsers assume that a short error page is the default page from the web server and decide to show their own, presumably more helpful text.
More info.
The implementation of error handling is browser dependent. In HTTP if you are just going to return a 403 error then you have to rely on the user agent (the technical name for the browser, the recipient of your error message may not be a browser) to handle out how it sees fit.
If you don't like how the browsers are handling 403 errors and want to ensure a consistent user experience across all browsers then redirect the user to your own 'permission denied' page. You can build a page that can explain to them why permission was denied and what they might be able to do about it. And it will be consistent for any browser.