I am using ASP.net webforms and successfully integrated the payment gateway. The problem I'm facing is that while I'm posting data to the payment gateway it process the payment and send backs the response to our web application and user gets logged out i.e. because user session getting cleared and sets back to null .I thought this occurs because of HTTP to HTTPS connection as every gateway uses https as a security. and after getting redirected to https it removes all the cookies and session data.
Later I have run the solution by enabling SSL in IIS express to make sure that the redirection happens from https to https, but still the problem persists.
Please help me fix this issue.
Related
I was trying out the curity configuration for an authentication service and a token service for OAuth and OpenID Connect locally. After all the configuration, when I was trying to test it with OAuth Assistant, I get an error:
Bad request
The request could not be processed
In the terminal, I can see these two INFO logs for particular
se.curity.identityserver.util.AllowedFrameOriginUtils - Requested origin is not allowed: 'http://localhost:...'
se.curity.identityserver.controllers.authorize.AuthorizeOAuthRequestModelProvider - Could not establish the redirect uri for request and client www. If this error occurs *after* being redirected to the authentication service and back, then this error has probably occurred because the original session cookie has been lost. Ensure that the cookie named 'sessionid' was sent to the authentication service. If not, check that the user's browser is not withholding it (for example by the cookie jar becoming full) and that a reverse proxy is not interfering with it.
There is no issue with sessionid. Anyone know how to fix this issue?
I am not sure the title of the posting truly describes my issue but here is what's happening, in more details. I have an ASP.Net MVC application that redirects to a page hosted in an external system. This external hosted page is used to enter the details of a credit card in order to process a payment. Once the payment is processed, the hosted payment page is sending an HTTP POST to a webhook URL which was provided by me, when the transfer to the HPP was made. I have a Web API controller in my ASP.Net MVC application and this will be used to receive the webhook call. Now, to test it while I am running everything locally, I had to use ngrok to create a private tunnel between the HPP and my local Web API endpoint.
I have a breakpoint in my Web API controller and I am getting the data sent by the HPP, data that contains details about the approved payment. The controller responds with an HTTP 200 which I see it in the ngrok console:
For some reasons, this HTTP 200 is not propagated back to the HPP which should display a back button to yield control back to my web application where we all started in the first place. Instead, the browser is directed to an URL which is the exact URL for the webhook, the one that was provided when the transfer to the HPP is made:
Any idea why this is happening? Is the ngrok not returning the HTTP 200 back to the caller, which is the hosted payment page?
Any suggestions would be greatly appreciated.
TIA,
Eddie
Turns out that this is not an issue with ngrok. The remote Hosted Payment Page (HPP) is not sending an HTTP POST to a RESTful endpoint, as I erroneously assumed. Insted it is returning to a specified URL and sends the response as hidden fields.
So if anyone is ever facing the same situation, please make sure you understand exactly the behaviour of the remote server. This could send the response as an HTTP POST sent to a specified URL or could yield the control back to your application by means of navigation where the response is send as hidden fields (HTTP POST with content of type "application/x-www-form-urlencoded").
I have a relatively simple setup where I am using stomp over websockets to retrieve data from my backend to avoid resetting the session timeout. I am running into an issue that mostly happens when I restart my server. I reboot and I am properly prompted to login. After the login succeeds I am redirected. However instead of being redirected to the page I requested I am redirected to the stomp endpoint.
I suspect this is a timing issue where the stomp client is continuing to connect to the initial stomp http endpoint after the server starts up and is overwriting the request to the page with a request to the stomp endpoint.
Is there some way to make the stomp endpoint not a valid target for a login redirect?
This seems like it is really only an issue during dev since it really only occurs when the server is restarted. However, with my dev environment being deployed on push I dont want the testers to report this as an issue.
I have a WebAPI, which is a part of a bigger WebForms app, deployed on IIS 10 under the https://domain/SimpleApp.
I have noticed that when calling an API endpoint using https://domain/simpleapp/api/endpoint I'm getting redirected (status code 302) to https://domain/SimpleApp/api/endpoint.
I didn't set any url-rewrite rules.
It is causing some errors when consuming the API on iOS app - some endpoints are secured, and when redirecting, the "Authorization" header is dropped (default behavior on Apple platform). For the record: the redirect occurs for both, secured and non-secured endpoints.
Is it some default IIS configuration? Can it be changed, so it will not redirect the request (or is it easier to handle this issue on the iOS app)?
Ok, I've found what was the issue. It is nicely described in this post: Beware WIF Session Authentication Module (SAM) redirects and WebAPI services in the same application
How should I access the share point web services in iOS which need to be authenticated by TMG. When I invoke login request it returns login HTML template in response as shown below
Can we authenticate TMG firewall somehow in iOS. I am not expecting whole source but any help, references will be appreciated.
Finally we got solution to this stuff. By requesting site info using GetWeb method like
"SOAPAction" : "http:\schemas.microsoft.com\sharepoint\soap\GetWeb"
along with a username, password we received cookies. Then passing these cookies to next share point services we received response and resolved above TMG auth issue.