We're calling a REST-API technical profile in the OrchestrationStep. In the event where the REST-API returns an error, it redirects back to the application and displays the error as a query string.
(e.g.#error=server_error&error_description=AADB2C%3a+No+code+provided%3a+Conflict+error%3b+RequestId%3a+No+request+id+provided.%3b+Additional+Info%3a+No+additional+info+provided.%...)
Is there a way that instead of displaying the error in the query string, it will display a custom error page?
Also why is api.error not displayed in this case?
Note: The REST-API is needed to be called in the OrchestrationStep rather than the ValidationTechnicalProfile
Assuming you are using Oauth/OpenId, the way B2C responds to the application is based on the response_mode query parameter that's passed to it when you call the policy. The response_mode can be query, form_post, or fragment.
Here's a link to the Microsoft's auth code flow docs that shows the response_mode query parameter in action along with it's available options: https://learn.microsoft.com/en-us/azure/active-directory-b2c/authorization-code-flow#1-get-an-authorization-code
api.error only displays for unhandled exceptions and doesn't cover every use case.
An answer to another post (Error handling in Azure B2C Custom Policy REST Call) from someone on the engineering team states that anything but a 200 from an API halts the journey execution and returns an error to the app immediately, so unless you put the rest call in a validation tech profile, this is the behavior you're going to get.
Related
Short Version
Please read at the very bottom for a short version of the question.
Situation
In a question I asked last week, I struggled in finding a solution, which makes our asp.net error visualization waterproof, since there are some edge cases where the asp.net exception handling fails and hence no proper exception visualizations can be created:
How to properly set up ASP.NET web.config to show application specific, safe and user friendly asp.net error messages in edge cases
Desired Solution
As an alternative to the way I described there, in my opinion the best way to make the exception visualization reliable, would be to use the httpErrors-element in system.webServer as a failsave so that any error which is not properly handled by asp.net, leads to a generic error page which is shown based on the settings of the httpErrors-element .
To accomplish this, there must be two things possible:
Error pages properly handled by the application must pass through iis without being replaced with a generic error message
Errors which could not be processed properly in asp.net, must be replaced through IIS.
It is my understanding, that this very behaviour is meant by the existingResponse="Auto" parameter in the httpErrors-element.
The ms documentation states:
Leaves the response untouched only if the SetStatus flag is set.
This is exactly what is necessary: Any successful error page creation in the application (through Application_Error or through an explicitly defined error handling page) can set
Response.TrySkipIisCustomErrors = true and IIS would let the error page pass through. However, every other error which was not successfully handled by the application in asp.net, would not set the flag and hence get the error page which is specified in the httpErrors-element.
The Problem
Sadly, it seems that in MVC5-applications (I don’t known whether the same behavior is true in other environments), the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) seems to be set automatically to [true], even if it is not set by the application.
Hence we are at the same place, as in my other post: If the error handling of the application blows, there is no way to show an application specific error with existingResponse="Auto", since its not possible to reset the fTrySkipCustomErrors flag.
As an alternative, one can set existingResponse="PassThrough". That's what we do currently, since we want to generate our error pages with a support-code and other helpfull information about the error to be shown to the user, or one can use existingResponse="Replace", but this is not an option, since it replaces any error page so that we don’t can show the user any error-specific information such as the support-code mentionen before.
Quesition in Short
The question is therefore, how to make sure that MVC5 (asp.net) does not set the fTrySkipCustomErrors flag automatically to [true], since there are situations, where no application code is executed and hence the Response.TrySkipIisCustomErrors (fTrySkipCustomErrors) cannot be set to false, what renders the existingResponse="Auto" parameter moot.
To check such a situation where the asp.net MVC5 exception handling blows but the fTrySkipCustomErrors flag is set to true, please request the following page from your MVC5 application:
http[s]://[yourWebsite]/com1
Please note: I'm not interested in disabling the above error. It's an example. I want the error visualization reliable and not to have to circumvent every error that possibly can blow asp.net's error handling mechanisms.
I'm trying to learn J-Meter.
When I'm running a sample script of logging into a site using both valid/invalid credentials,it doesn't stop thread execution when invalid login credential is used and also login is not recorded in database.
Does it actually login to the website or only creates virtual login to create a similar environment.Is there any way to achieve this using Samplers?
JMeter is/acts as a headless browser.
Whatever your browser with an UI does, JMeter can also do - except executing a javascript. So, If you had recorded your script correctly - JMeter can login to the actual application as well.
Jmeter is not like QTP/Selenium. It does not know if it is a valid credential/invalid credential. It passes/fails the request based on the HTTP codes. If the HTML response from the server comes with a 200 http code, It passed for JMeter. If the server responds with code 500, JMeter fails the request. But JMeter also provides a way to validate the response you get - Assertion. You can use Response Assertion to see if you are seeing the home page or not to confirm if the user has logged in successfully.
To stop the test on error, select the appropriate option here in thread Group properties.
JMeter is a very nice tool & have been using it for 2 years with no issues.
Good luck!
Does your script have Config Element -> HTTP Cookie Manager? It needs cookie for the login function.
If your script has many transactions with the same level with login transaction and the option you select in your Thread Group is Continue, all transactions will be executed no matter login transaction is passed or failed.
In case you want the other transactions will not be executed if login fails, let add a Regular Expression Extractor as child of the login transaction to retrieve the text Dashboard, put other transactions into a Logic Controller -> If Controller. Suppose the Regular Expression Extractor has name Dashboard and Default value is NotFound, then the Condition of If Controller will be "${Dashboard}"!="NotFound"
JMeter automatically treats 2xx and 3xx HTTP Response Codes successful so it won't be able to detect failed login unless you explicitly tell it to check presence or absence of some specific content in the response data.
So if you add a Response Assertion you will be able to conditionally fail sampler and choose what to do in case of failure via "Action to be taken after a Sampler error" on Thread Group level.
See How to Use JMeter Assertions in Three Easy Steps guide for more details on the assertions domain.
If you're unsure what JMeter Sampler is doing you can check request and response details via View Results Tree listener. If you cannot simulate login event in majority of cases it is due to missing HTTP Cookie Manager and/or failed correlation of dynamic mandatory parameter(s) like Viewstate, CSRF token, etc.
i'm trying to follow the example code on google's website here, but it seems a little broken - the javascript references getting a list of people from the server, but in the server-side code there's no reference to calling those functions of the api, it just returns an HTTP status code and a text status, so i'm wondering if there's a step missing and i'm exchanging the wrong code at the wrong time.
my current flow is
login button button clicked, magic happens, my callback gets passed an object with a whole bunch of properties in it
I take the code property from that object, and post it back to my server in an ajax request
on my server, i run the following python, where auth_code_from_js is the data of my post request:
oauth_flow = client.flow_from_clientsecrets('client_secrets.json', scope='')
credentials = oauth_flow.step2_exchange(auth_code_from_js)
python throws a FlowExchangeError with the message invalid request and no other useful information
am i missing a step? is that initial 'code' property what i'm supposed to be passing in to the 'step2_exchange' method?
I am facing to a trouble with 2 adapters based authentication. My app is agenda (hybrid app). All adapter's functions must be protected by security.
my app uses adapters based authentication, like written in samples on DeveloperWorks.
My first adapter (loginAdapter) is dedicated for login (beginning of the mobile app). I developed a handler (handlerLogin, mobile side) with methods isCustomResponse, handlechallenge, etc.. This adapter works.
This adapter allows to get a userId from login and password.
As soon as connected, the user can download his agenda. The mobile calls an other adapter based auth (calendarAdapter). I have an other handler (handlerCalendar) with methods (isCustomResponse, handlechallenge).
When the mobile calls the method getCalendarData (protected method, CalendarAdapter), the server detects that the user is not registered for this adapter, that is why the server send an error (structure authrequired + errorMessage) via the function onAuthRequired.
At this step, all works fine.
Actually, the trouble comes from, that, the first handler (handlerLogin) catches this error, whereas it schould be the second handler (handlerCalendar).
Given that it is catched by the handlerLogin, isCustomResponse and handlechallenge are called, and I do not have the expected result ! I do not know why.
Why it is not catched by the handlerCalendar ?
I verified my code, variable's names, files, etc.. All things are ok.
For informations, I first declared the handlerLogin before the CalendarLogin.
Do you have any ideas, suggestions ??
Thank you in advance
It looks like you used the same realm.
The isCustomResponse function job is to find out if this challenge-handler should take care of this specific request. If you use the same realm for both adapters then the 2 challenge-handlers will react to it.
Let's say that a request is sent to server via xhrPost and server finds that request needs more information to be processed (for example a variable is missing), so, a response is sent back to client informing that request may have not been completely processed and this message is shown in a dialog box.
I was doing it sending from server an HTTP 202 status code, which I believe is not correct, and treating it on load function, where this message was displayed on a dialog box. But if I respond with some HTTP error code (ex: 400) the error is displayed in console (Note: in this case the message is treated in error function), as well as in my dialog box.
What is the best and correct way to do it?
Note that it is called a load handler, not a success handler.
The load hander is for valid, well formatted responses. These can contain a verity of status codes generated by your server side app that indicates success, failure, or something in between.
The error is just that, the server blew up while trying to process the request and whatever you get back is probably not something your widget was written to expect. For this reason, I recommend using the same error handler across your whole app.
The dojo documentation states:
Sometimes xhrGet calls will fail. Often these are 404 errors or server errors such as 500. The error parameter is another callback function that is only invoked when an error occurs. This allows you to control what happens when an error occurs without having to put a lot of logic into your load function to check for error conditions. The first parameter passed to the error function is a JavaScript Error object indicating what the failure was. Dojo doc