Looking at my website in IE8 in windows XP, cookies work fine. But, when i connect to my local dev version over the local network, it's not saving cookies. I'm connecting via an entry in my c:\WINDOWS\system32\drivers\etc\hosts file.
I'm not that familiar with the intricacies of IE8's security settings. Could there be something that the live site does, which the local version doesn't, which means the local version is failing some security test and thus not getting its cookies saved? IE8 is on the default "Medium-High" security setting. I've tried changing it to "Medium" (the lowest) and get the same problem.
When i say it's not saving the cookies, i mean that i'm looking in the IE8 dev tools/Cache/View Cookie Information page, and it's totally empty (apart from the site url) - there's no cookies saved at all.
Hoping to get some pointers on this, i don't really know where to start trying to fix it.
thanks, max
Ok, figured it out - the hostname i was using had an underscore in it. When i changed it to a hyphen it worked fine.
thanks for reading!
Related
recently I came across this issue when I exposed my port via ngRok.
I simply forwarded it but when I tried to open the ngRok url I got Deceptive site ahead warning.
Here is the image of the warning.
It was a django server with graphql and I wanted to test graphiql. (this point might not be necessary for the reader but more info is always better than no info)
So the solution I found was to click on the red empty area and type "thisisunsafe" (without quotes of-course)
PS: I searched for the solution but couldn't find any I hope this will help others who are looking for the same.
Another workaround that I found is using that same URL in an incognito window. I'm not sure why the security is more lax there...but it works.
We're integrating SAP Commerce 2005 and Spartacus 2.0.3 with CDS (Context-Driven Services). We followed the instructions from https://sap.github.io/spartacus-docs/cds-integration/ and we got it work right.
Nevertheless, we've noticed one issue.
When we clear the site data (either from Chrome DevTool or via browser Settings), the cookie named profile.consent.given is not being set anew while refreshing the page - even though the PROFILE consent has consentState "GIVEN" in local storage in spartacus-local-data > anonymous-consents > consents.
Initially I thought that it's just not visible in DevTools, but when I've added the url parameter ?profileTagDebug=true, in the console there is a log saying:
"[Profile Tag] No cookie found with name profile.consent.given".
When I set this cookie manually with value true, everything starts to work just fine, all other needed cookies and local storage data responsible for tracking users behavior is being set properly.
Do you see any place where we could have done something wrong, which may have caused this cookie to work improperly? Which module or component of Spartacus library would be of any clue in resolving this issue?
Edit: the reason of this strange behavior was in profile tag created by our team in CDS. It contained:
"consentListener": "type":"cookie","cookieName":"profile.consent.given","cookieValue":"true"},
which made the cookie profile.consent.given necessary while it shouldn't be. Using profile tag without this part made all work just fine.
With Spartacus, this cookie doesn’t make sense anymore. It is created by the Commerce backend and works best in combination with an accelerator frontend. Cds-spartacus in combination with ProfileTag relies on the anonymous consents or the user consents (depending on the user being logged in or not) loaded by Spartacus. More information about anonymous consents can be found here: https://sap.github.io/spartacus-docs/anonymous-consent/.
Just a quick FYI about the CDS-Spartacus integration: the profile tag script is pulled from the configured URL by Spartacus, and the script is doing all the event and data "scraping". The cookie is also being placed in the browser by the script.
Your question and this comment lead me to think that the script is not handling this case.
I'm not even sure if it should handle it, so it might be a better idea to contact CDS team directly about this one.
I currently have 2 of the same site (one for production and the other is a development version) on one server and I have an issue with the ember-simple-auth for both of the site. Whenever I log in on one of the site, it works perfectly fine, the session works and everything works as expected. However, when I have both of the site open on different tabs (on the same browser and same window) and I try logging on one of them, they both log out creating an error in the console saying:
"The authenticator "authenticator:oauth2" rejected to restore the session - invalidating…"
On the other hand, when I have one of the site open on a regular browser and the other one on the same browser but in incognito (no caches), they both work perfectly fine (e.g. none of them logs out and everything works as expectedly). It works perfectly fine too if I open one site in one browser (such as Chrome) and the other site in a different browser (such as Safari).
My first guess is that these 2 different site has the same session used in cache but I could be wrong. If you have any idea on why this occur or you have a solution, please let me know.
Probably both sites are on the same origin and you use the local-storage session-store. Then both will use the ember_simple_auth:session localStorage key.
Probably the easiest thing could be to override the session-store and define a custom key that contains the information if its the dev or production build.
The probably easiest thing is to have both sites on different ports and/or domains so you have a different origin.
I'm using Liferay 6.1.0 GA1.
My applications runs on two tomcats. I have varnish in front of them. Varnish redirect to particular node when cookie is set on it.
When I'm trying to upload multiples files on Firefox, it loses this cookie (on Chrome it works just fine).
My idea was, to extend URL - add parameter that can later be filtered in Varnish. But I cannot find where should I add this, that Flash can later copy this properly.
Any other ideas that will be helpful are welcome as well.
P.S. Sorry for bad english.
"Loosing a cookie" means that it explicitly is set to another value, or the hostname changes. I suggest you use Firebug or the built-in Developer tools (hit F12) and monitor the requests and responses that go through the line. Pay attention to Set-Cookie directives in the response headers as well as the Host directive in the request headers. This should give some hints where they're going.
It's hard to give more specific advice with the level of detail you provide.
I have a few related selects that work perfectly on a testing server with very loose security (basically just a simple default install of CF 10).
I have tried to implement the CF 10 lockdown guide on the production server and all seems well, except that related select don't work. That is, the first select in the chain doesn't populate and therefore, none of the related selects populate either.
I even recreated Ben Forta's art media example: perfect on the testing server, no triggering in production.
All other CFC functions seem to work: SELECT and INSERT queries are just fine. Only CFSELECTs with bindings are hosed. I pretty sure that the problem is a server configuration. The same pages worked just fine on our old CF 9 box. Any ideas would be helpful.
My advice to you would be to NOT use cfselect or any other UI stuff in ColdFsuion - It only causes more headaches than it gets rid of.
That being said, if you followed the lockdown guide, you should have limited access to the CFIDE directory - which is needed for any of the ColdFusion UI stuff. There is an option in CF Admin to use a 'custom' path for the scripts ColdFusion uses - it is on the main Settings page. Set this value and create a virtual directory in IIS with the same name pointing to the {cfroot}CFIDE/scripts directory.