I have a site (built on LAMP (cakephp) and has ssl certificate installed) which has a secure payment page. After filling up necessary information user proceeds to a payment gateway page. After all the process at the gateway end, gateway redirects to one of my URL, which I have to mention with a payment request.
Now when I keep this url as http redirect happens properly and all the sessions are maintained. But I want to make this page as https, and when the payment gateway redirects to the https version of the URL, my session information dies and I get redirected to my home page.
eg: my payment page
https://www.mysite.com/payment
from here user goes to the payment gateway site, does necessary things and payment gateway redirects it to
http://www.mysite.com/paymentResponse (this url i have to mention in the request)
now i have to make this as HTTPS, but when I do that my session info dies
Plz help me
Thanks,
Dinesh
I don't know why it supposedly works for plain HTTP requests, but the problem may be related to Configure::write('Security.level') being set to medium or high, which activates PHP's session.referer_check, which may be the reason sessions are dying for you when being redirected from external sites.
Related
I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
I have a tornado webserver with login page:
If the client try to access any endpoint it checks if the user is logged in and if he isn't then is redirected to login endpoint for the user log in.
The problem is that if i allow cache in the browser then when i access to any endpoint i have been before, the browser try to be clever and begin to requests all css and static files inside that endpoint despite that all of the requests are being redirected to login page provoking strange behaviors.
I could add in all my responses no-cache headers but i wanted to know if this is a good approach or is there a better management of this case.
I have no idea if anyone experience this, i have a slight problem when redirecting from paypal to my site back....
I have a site built with angularjs + php in the backend of it, i log in to my site and everything is fine, When i try to do a recurring payments, it redirects to paypal, i accept the payments and such, when i come back to my site (review payment) i have in the url the payer id and token, which is exactly what i need.. but im not logged in anymore to my site.
The problem with this is, if i do reconnect to my site again, and do the same procedure, now it's all good...
What can be the cause of my site to log out the user when it redirect's back from somewhere, in this case, from paypal?
Take a close look at two requests from the browser to your website:
- the last one before redirection to PayPal
- the redirection from PayPal
Open the Network tab in FireBug or Developer Tools, depending on your browser, and examine the values sent in cookies.
Check if your browser accepts cookies (assuming it's cookie-based sessions you are using)
Make sure there is a cookie created by your PHP when you make the first one
Make sure it is still there, sent from the browser when you come back from PayPal
Make sure the values in the cookies (session ids) match
Also, that the server does not send a "set-cookie" header in the response to the second request
A "no" to any of the above opens a few more options to investigate, so start with these.
I have read on some blog (sorry for not mentioning the reference but I can't find it anymore) that you will lose all your work on securing your site if you redirect a user from an https page to an http page.
So, could someone please explain to me if I am right or wrong here in the following scenario:
Is it right practice to use https on the login page then redirect him to Admin Page with http, or will this will create a security issue like Session Fixation hijacking, stealing session, etc.?
Or must I keep the Admin Page also in https?
Another side of the question is: will https allow caching of static files?
I have read other articles here but I am still confused as some say 'yes' and some say 'no'; also some say it depends on browser.
In your instance (in only securing the login page with HTTPS) while login details will be protected (e.g. username/password), your users will be susceptible to Session Hijacking.
Whether you use a mixture of HTTP/HTTPS or full HTTPS depends on your situation. Amazon for instance, will use HTTPS for the login, but you'll browse the site with HTTP, but as soon as you go to a sensitive area (Order details screen, change account/password details etc.) it switches to HTTPS and asks you to re-authenticate. Re-Authenticating the user after switching from HTTP to HTTPS is the key to stop Session Hijacking because you're effectively issuing a new Session token. So if a user steals the session token, they still don't have your username/password and can't access your account section.
If the admin area is particularly sensitive then just HTTPS the whole thing. Google found the overhead from using full HTTPS was between 1-5% overhead on the CPU, hardly anything basically.
As for caching static files on HTTPS I'm not sure, but this SO post suggest it'll cache as normal Will web browsers cache content over https
Everything must be used with https. If you switch over to http, everybody can see the content being sent, which means those security issues you mentioned will emerge.
The reason is that you have to identify your client in order to assign access rights in your admin site. One possibility to do so, is sending back a token (some hash or whatever). Depending on the token you know if it's an authenticated client or not. But everybody else does see this token => security issue.
Of course you could use the previous https session to exchange a private key. And use it to encrypt your http stuff somehow. But this is a bad idea, since https does this much more conveniently..
We integrate with SagePay Server using ASP.Net and we seem to have a problem getting session on our NotificationUrl.
We get no information when we try to read session on the Notification page, but strangely the page we set as RedirectUrl can read all the values from session. Can you please advise if we are doing anything wrong or if we have to pass any parameter to access session information on the notification page?
Thanks,
PS: I have also posted the question on SagePay support forum
If I'm not mistaken, the request to NotificationUrl will be done from SagePay server and not customer PC, therefore request will not have customer's cookie/session id that is valid on your server. From your server point of view they (customer and request to NotificationUrl page) would be 2 different persons. Check your web server logs -- they will have different IPs and most (if not all) requests to NotificationUrl would be from the same IP (or IPs in the same subnet).
The RedirectURL is usually a page hosted on your own site which is designed to be an order complete page that we redirect the shopper's web browser to upon transaction completion.
For more information on this, please check Sage Pay Server Protocol and Integration Guidelines.