I am trying to upgrade Authorize.NET from CIM to Accept Hosted, and stuck on this problem:
Authorize.NET Accept Hosted needs 2 urls for the configuration.
Return URL, which redirects the user to home page, after a successful payment.
A webhook url, to which the Authorization.Net webhook will post transID.
On redirect, I need to access application specific payment details, which are stored in the current session. Note: These are not the authorize.net payment details, I can get them from webhook->transID->GetTransactionDetails
In CIM, the redirect url contained the Payment information from AuthorizeNET(transID, etc.), as well as the app-specific session Payment information. So I was able to process both of them in a single handler, which was called on the redirect.
However in the new api, when a webhook sends post data on my webhook URL, it does it asynchronously, using a different session than the session on which payment was made.
So when I receive transID and subsequent payment details from AuthorizeNET, it has no idea about the session dependent application specific payment details.
My question is, how can I preserve the session-specific data, after I receive the Authorize.Net's payment details?
Has anyone encountered a similar problem? What's the best approach to fix this?
You can't maintain a session across systems so you need an alternative way of storing that data and retrieving it once the user returns to your site. A common way to do this is to persist that data in a database and storing the identifier for that data in a cookie or in a custom field that Authorize.Net will pass through for you as part of the transaction and returning redirect. In this case the return URL you pass in hostedPaymentReturnOptions.url can containa query string with that identifier (i.e. https://www.yoursite.com/return_url?id=12345). Then once the user returns back to your site you can use that identifier to retrieve their session data from the database and add it back into their session.
Related
Need help to understand standard flow for handling additional-information-required scenario.
Context: We have a number of product implementations, all integrated with a central single sign-on server. A registered customer can opt to start using new products on-demand. But some of the products require the customer to carry out some one-off setup steps before they use the product - these steps are only needed the very first time of using the product.
Consider a customer is on the page https://product-abc.ourdomain.com. And now clicks on a link within that product something like 'do something (note, this will redirect you to product-xyz)'. At this point the customer is redirected to https://product-xyz.ourdomain.com. Here we want to detect whether the customer is using the product for the first time and if yes, redirect the user to a setup page wherein we can prompt them to supply the product-specific additional information. On the other hand, if the customer is already configured for the product, they will just navigate into the product page and continue using it.
I wanted to know if there is something similar to the 401 Unauthorized flow to handle this. With authentication flow,
A client tries accessing a protected resource.
The server checks the caller has requisite authentication and if not, returns 401 Unauthorized status code with additional details in the WWW-Authenticate header.
The client carries out authentication - say by integrating with the central single sign-on server - and then reattempts the original request, this time succeeding.
I'm wondering if there is a similar flow like,
A client tries accessing a protected resource.
The server checks whether the client is OK to use it. In our case, if its the first time a customer is accessing the product, this check will determine additional setup is required. For example, the client has to supply us with their correspondence address so that we can set up a data tenancy for the specific customer. Here I would like to return a HTTP status code, say, 4xx Setup Required with additional information in a header, say, WWW-SetupInfo.
Once the initial-setup flow is completed, the customer will be redirected to the main product and carry on using it.
The nearest status code that seems to match my usecase is 402 Payment Required, but product-xyz doesn't need any specific subscription or payment. We just need some product-specific additional information to do the initial configuration.
I can handle it by doing custom implementation using 3xx redirect but I was wondering if there is a better way of handling it.
Thanks for any pointers.
Unless you are using basic-authentication, you don't want to use a 401 Unauthorized" status code with a WWW-Authenticate` header. This built in mechanism in browsers has very limited functionality:
Always prompts for user name and password, with no mechanism to customize the process either with look and feel, or custom workflows. You say you want to use single-sign-on. 401 Unauthorized is not compatible with that.
Has no log-out mechanism
Has no session timeout mechanism
As a result, almost all websites use logins based on forms and cookies. If somebody isn't logged in, you should use a 302 Temporary redirect to the login page.
Similarly, if somebody doesn't have their initial setup completed to use a particular page, you would not use a special HTTP status. You would either present them with the a 200 OK page with the form asking for the data you need, or use a 302 Temporary redirect to take them to that form on another URL.
A lot of times there's a parameter in a partner API endpoint like success_url where you provide the partner API with an endpoint on your internal API to redirect the client.
For example, on Stripe you can create a checkout session using POST /v1/checkout/sessions. In the body you send Stripe a success_url. You redirect the client to Stripe where they make their payment. After they complete their payment successfully, Stripe will redirect the client to that success_url you included.
Since you are only sending a URL aren't all of these requests only GET requests? And if so, a GET is defined in the HTTP protocol as idempotent and safe. So I couldn't use this request to make changes to data on my server. But after a successful purchase, I will want to make changes like updating or creating an Order on my server, updating stock left for the Item, etc.
How can I make changes after these success, refresh, return, or cancel URL's if they are all GET requests?
I am developing an application that posts comments into Merge Requests on Gitlab. It works by authenticating with a given user, and then after some setup will register a webhook on the relevant project to be informed when a Merge Request update happens. When a new Merge Request is detected I want to post a comment on the Merge Request asking for some specific detail to be sent over.
However, when we post the comment on the Merge Request we can only ever seem to do it as the user that we have the OAuth token for (which of course makes sense). My question is what should we do/could we have done in order to post the note as a 'bot user' without having to register a full user into the repository? Or is this just impossible?
You can create a reporter user and use its access token. The problem my arise when the user doesn't have enough access control.
You can create a project scoped token, a bot user will automatically be created for such a token
Ref: https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html
I'm currently working on a web app which will allow a user to subscribe to push notifications. We'll store the subscriptions in a database table mapped against the user's ID and when a notification needs to be sent, we'll look up the user's subscriptions and send the notifications.
I've been following this guide:
https://developers.google.com/web/fundamentals/codelabs/push-notifications/
All is going well, but something just doesn't feel "right".
On every page load, the service worker is registered, then it checks if they're already subscribed, then even if they are it calls updateSubscriptionOnServer() which contains the following comment:
// TODO: Send subscription to application server
This effectively means that every page load is going to be attempting to write the same subscription back to the database. Obviously we'll handle that in the application, but it doesn't seem ideal.
With the Web Push API, is this the expected approach?
Many thanks
Yes it can be useful to send the subscription to server on every page load:
The user may have changed permission from blocked to granted (or default) in the browser settings, so you want to create the subscription and send it to the server
The subscription endpoint may change for different reasons, so you need to make sure that the current endpoint is sent to the server (the previous endpoint will return 410 Gone)
A compromise between the points above and performance can be to send the subscription to the server only on given pages (e.g. homepage).
I'm building a payment page in asp.net, however the page where you order your items is run in HTTP (non-secure) on my domain.
When redirecting the user to the payment site, I have to go through a different domain (my payment provider, from whom I borrow the SSL certificate), so my payment url ends up like https://www.paymentprovider.com/somescript.cgi/www.mydomain.com/mypaymentpage.aspx
Now the problem is my session is lost, but I store the order in session, so I desperately needs it.
Can I somehow send the SessionID in querystring, and restore the session from it - or do I need to stuff the entire order into querystring ? (Not too certain it'll fit though, it's rather long)
Any help will be highly appreciated :-)
Steffen
the correct way is to use a unique orderId that you send with the payment, and then the payment gateway its send it back to you.
Its not so simple as its sounds because for security you need ether to encrypt the orderID, and send it and get it encrypted, or else everyone can see and change your orders, ether communicate with the payment gateway with some kind of encrypted protocol.
Paypal do this way, with your order you need to send to paypal a unique ID that you can use it only one time for one transaction, and then paypal make the reference base on this ID.
The other way you say with the session and the cookie is not safe and both can expires, lost, what ever. The session is saved on a cookie anyway. Longer time on session can make what you all ready have to work - but its unsafe and randomly to what ever happens to session or the cookie.
Why don't you load the Session into a Cookie right before redirecting, and when the user reaches your payment area, re-create the session from that cookie?