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?
Related
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.
I am Creating E-Commerece Website For Kirana Using Session Of Data Table But Now I want To Use Cookie To Reduce Traffic With Cloud Is This Safe method Or not? I try to Use Cookie and pass parameter of session id to it to remove (i.e. Clear Session Variable) when Shopping is completed but it is not working still cookies are store in to the browser. Please Specify me the solution?
Cookies are delicious, nomnomnom (XD just kidding). Some clients have their cookies disabled. "Cookies CAN be used for malicious purposes though" -from http://www.allaboutcookies.org/
For me, Sessions are safer
Cookies can be edited by a user.
Sessions are strictly serve based and can be controlled on the server side.
Session is the way to go. That way you can keep information about each user in their own unique session.
What we have currently implemented works well but I'm just concerned that there maybe a better way or we are doing it completely wrong.
Once logged into our website, on each and every request it will make a request to the API to get the users details.
E.g. Username, ImageUrl, Roles / Permissions, Email Address etc
It then stores this data in the BaseController for the viewpage or anyone else to see during that request.
Upside:
to doing it this way is that you know each request that the users permissions/roles and their details are all up to date!
Downside:
Your most likely to get exactly the same data every request, until that one day they change their details. Thus your possibly making unnecessary calls??
However the first way we tried all this was when the user logged in all their data gets stored in the cookie, the problem with this is that our users hardly ever logout so all the data that is stored in the cookie gets stale often. -> Stale Roles/Permissions is an annoying issue!!!
How does everyone get around the stale data from login.
I would go back to your initial approach of storing the claims inside the cookie.
If you do indeed have very long log in times then I would guard against stagnant claims by periodically refreshing the cookie.
If you are using forms authentication then you could intercept the FormsAuthentication_OnAuthenticate event in Global.asax, decrypt and manage the cookie (here), validate the user and cookie first then run a quick conditional check against a custom field in the userdata property, called refreshedDate.
If the last refresh date or creation date is greater than some configurable window then call to the database and refresh the claim data from the database. Finally update the refreshDate and claim data and update the cookie.
Update
Following on from your comment...
Just to say that it is not uncommon to hit the database for each request, that is to say I have known it happen in a number of production systems. Many people are probably using ASP.NET session state using MS-SQL database's. Typically I have seen it when there is a real security need to invalidate someone's session, deny access and log them out immediately.
If your database is on the network locally to your web servers and/or latency is acceptably low then it can be a perfectly workable solution. Just make sure your database queries are minimal and performance tuned to perfection, consider side steeping any ORM (if applicable) and use raw SQL connections to make things as fast a possible.
If database latency is high, the other middle ground solution is caching, using Redis or Memcached to house the results of your queries and invalidating the cache when permissions are altered etc... but obviously adding the required infrastructure and operational support for caching solutions is a serious consideration.
You can apply an expiration to the cookie; that way it dies and requires them to login. Or, keep their user ID in the cookie, but store their profile info in session. When session dies, the next time the profile is checked if it is null, make a query to the API again. This way, it's getting updated more frequently.
In addition to other suggestions, another option may be to use a notification mechanism from the underlying role/permission store whenever a user's data changes. This notification could then be used to invalidate the cached data on the web server. This would ensure that the cached data is returned in the majority cases but the store would then be hit only when the data had changed.
If the underlying datastore is SQL Serevr then consider something like SqlDependency.
This is obviously a more complex architecture but it would meet your requirement and only you could say whether it's worth the effort / complexity / tradeoff!
I've got a site that uses Forms Authentication (with a custom membership provider, but that's not important right now). In the secure part of the website, the customer can purchase goods and pay for them via WorldPay.
Once they come back from WorldPay, if there's a link back into the secure part of the website, can I reasonably expect the forms auth ticket (stored in a session cookie) to have survived (timeout notwithstanding)?
The ticket is set thus:
FormsAuthentication.SetAuthCookie(username, false);
FormsAuthentication.RedirectFromLoginPage(username, false);
The work is part of a redevelopment, and I would rather have a quick "yes/no/maybe" answer before writing lots of code that may not be required - we do not want to have the user log back into the secure part of the site so we recreate their login based on the information returned from WorldPay. Obviously, if the user is going to be remembered, I don't have to write that code - I'm quite lazy ;-)
Thank you for any suggestions,
Mike K.
Forms Authentication uses a cookie.
A session cookie (which is stored in memory) lives as long as the session does not timeout and you do not close the browser.
You may also be able to set the life time of the cookie, then it will be written to disk, and available to all browser instances. In this case you will also be logged out if the session timesout on the server.
If you're calling
FormsAuthentication.SetAuthCookie(username, false);
then the cookie will survive for as long as the value specified in your web.config or until the user logs-out.
If you redirect them to a 3rd-party site during the course of their visit to your site, this cookie will remain. The 3rd-party site won't have access to your auth cookie.
In short, they will still be logged-in on your site when WorldPay redirects them back.
Even shorter: yes.
Hope this helps.
The other answers here seem to point out to this being a non-issue, but I thought I'd just add that if you're posting data to their gateway, any variables which start with MC_ will be returned to you on the other side. I'm not sure if this helps or not!
I've got an existing site I'm taking over, and right now it stores, in a session variable, the id of the currently logged in user (if logged in at all -- otherwise I'm sure it is empty string or null or something).
The client now wants, after someone is logged in, to "keep" them logged in on that computer for an indefinite amount of time.
ASP.net Sessions have a maximum idle time of 1 day, I believe. The website isn't written all that well in the Flash portion (whole front end is flash) and the flash will process a login, then, as long as the flash isn't reloaded, assume that the user is still "logged in".
I think my solution is to ALSO store a client side cookie with some GUID value and hold in the database the associated user id...sort of like a session that never expires. So, when the page is loaded, I can check my cookie, use that to select the userid out of the database, and if we find one, then set the session value that says user 23 is logged in.
Does anyone see any issues with this perspective? Would you recommend something different? I really don't want to refactor a bunch of the existing code, but just slip this in on top...
PS -- security is not really a concern. The only reason they have people log in is so we can track orders by a person, but no money changes hands through this website. There is also no personal information that a user can view or edit, either.
This is how I do it. I actually have a cookie that holds their login and password, this way I can automatically log them in should they not be logged in. I expire the cookie after a couple of days of inactivity. The downside is that everyone forgets their password because the only time they really have to enter their password is when they come back from extended time-off.
This is for an internal application, with the same customer demands that you have and this works ... and makes the customer happy.
One thing we may end up doing is just using Windows authenication, might actually work better in this circumstance.
That's the way I do it, but the problem with it (at least I think its a problem) is that when you store the username and password in a cookie there is not any encrypting when you add the cookie. If you look at the cookies in your browser the username and password are displayed there plain as day. Is it possible to get some kind of encrypting on the cookies you store? Or how would you handle this?
Check this blog posting out http://timmaxey.net/archive/2009/03/06/asp.net-cookie-auto-log-in.aspx basically you needs to save the cookie with a guid a series, and a token, the token, in my case, changes all the time, the series is something that is generated based on something, like the guid and id combo or whatever, then the guid is always stored with the user. There is a cookie table to stored this info etc... pretty secure, not 100%, but pretty good... Tim Maxey
I recommend using the Enterprise Library Crypto App Block to store an encrypted cookie which is nothing more than a GUID. Get the GUID, and use a session table in the database to track user info.
At the session start event, get the user info and cache it.
Using the session object is not recommend for user info because it won't work on a web farm, unless you use a database for session state.
You're basically rolling your own session state at that point, and I'm fine with that. However, I would not go the route of storing the username/password in a cookie (even if encrypted). There's no way to expire that from the server-side. You can always remove your row in the table to force a user to log in again, but if they hold the username/password they hold the keys to the kingdom.