I'm having issues setting session cookies in Internet Explorer 3.0. Does anyone know if there is something special that needs to be done?
I'm doing with PHP, like so: setcookie('test', '1');
I'm not using a path or expiration time, is that necessary?
Perhaps someone has some old experience, or a 1997-1998 web development book laying around?
In case anyone is wondering why I'm bothering with this, because no-one uses IE3 anymore, and it's hard, yadda yadda, it's an art project.
Edit: Just to clarify, I have not tried setting cookies via JS yet, this is being done via HTTP.
I'm not sure the setCookie was around at this time. You could, however, use the older way of setting cookie which is
document.cookie = "someCookie=someCookievalue"
or
document.cookie += "someCookie=someCookievalue"
if you don't want to override cookie.
You can then retreive it using the document.cookie property. This will return a string of all the cookie. you can parse them using this function.
function parseCookie(cookiesString) {
var cookiesOutput = {};
var cookieKeysAndValue = cookiesString.split(';');
for(var i = 0; i < cookieKeysAndValue.length; i++){
var keyAndValue = cookieKeysAndValue[i].split('=');
cookiesOutput[keyAndValue[0]] = keyAndValue[1];
}
return cookiesOutput
}
document.cookie = 'someCookie=SomeCookieValue';
console.log(parseCookie(document.cookie));
I'm not 100% sure this will work since, you know, you are using Internet Explorer 3. But it is worth a shot.
If you need more information on that, you can consult the MDN doc
P.S. I tried to write something old javascript type as much as I could, but there still might have some errors. I already miss the modern browser feature.
So I've gotten to the bottom of this issue, and there were three causes for my confusion:
First, if you don't set a path= parameter for the cookie, IE3 will assume that the cookie is for this exact path only. This means that it will send back the same cookie when accessing /test.php again, but nowhere else on the site.
The solution is to include path=/ when setting the cookie.
Second, IE3 does not recognize cookies without an Expires parameter. The solution is to include Expires= in the Set-Cookie header, in "standard" cookie format.
The third is caused by the new Max-Age parameter, helpfully added by PHP for some reason, which IE3 does not recognize. Instead, it assumes everything up to and including Max-Age is the cookie name.
The solution is to set the cookie using PHP's header() function instead, like so:
header('Set-Cookie: test2=hi; expires=Tue, 02-Feb-2021 04:20:00 GMT; path=/');
(In this case, test2 is the name of the cookie, hi is the contents, and it expires about a year from today, on Feb 2nd.)
Related
I am writing a chrome extension that makes calls to an API and for that I am trying to get some existing session cookies in the service worker. My worker makes a call like this,
const cookies = await chrome.cookies.getAll({} )
const sessionToken = cookies.filter(
cookie =>
cookie.name === "__Secure-next-auth.session-token")[0].value
However the value I get back for the cookie is different than the value in chrome dev tools. Interestingly enough both values have the same prefix (the value is long, I only pasted enough to demonstrate my point):
Dev tools cookie: eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..dCOoryziuSU3zkJl...
chrome.cookies.getAll: eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..colJ2H6th0yLZ9Q8...
In case it's useful the cookies have the HttpOnly parameter set. Can anyone guess why the cookie values might be different?
My worker is running after the page has loaded (so there's no chance that I'm getting an old value), I know the value the chrome API is giving is completely invalid because when i try to use it with the API I'm calling, I get "invalid token". On the other hand, the cookie in dev tools works with my API.
I thought maybe the cookie value had been decoded/encoded in some way but then why would the prefix match? I thought maybe the chrome API is storing multiple cookies with the same name, but when I log cookies, there is only one cookie with this name.
Would appreciate any thoughts.
When you return to certain websites, sometimes they have popups or messages which show to inform users of new updates to the site or important changes.
I'm having issues understanding how these are implemented because these messages only show up once. How would a backend know that a user has already seen a backup and would it not be strenuous checking every time a page is returned to if a user has seen a certain message?
There are multiple methods which I have thought of to implement this functionality:
Storing a cookie which is checked by the backend to see if the user has seen a recent message or popup.
Have a table in a database named 'viewed_message' or something that states all the users that have seen a certain message or not.
How would a website go about creating one-time only popup/messages? Thanks.
Typically cookies are used for that sort of thing. Just check the existence of some firstVisit cookie and pop up the message if it's not there. Keep in mind this means if you clear your cookies you'll see the popup again.
edit:
This is an example from the Document.cookie docs on Mozilla:
function doOnce() {
if (document.cookie.replace(/(?:(?:^|.*;\s*)doSomethingOnlyOnce\s*\=\s*([^;]*).*$)|^.*$/, "$1") !== "true") {
alert("Do something here!");
document.cookie = "doSomethingOnlyOnce=true; expires=Fri, 31 Dec 9999 23:59:59 GMT";
}
}
I think you are on the way.
Cookies are there for that, create a cookie wich never expires and be happy.
If you want to use in wich others browsers, check if the cookies exists if dont look in table and store a cookie.
Via github I installed the 2.0.3.2. RC version on my digital ocean VPS. All seemed to work fine, but just like many others i got problems with the JSON syntax error. I spent hours reading through forum pages about
API users that have to be made
API users that have to be appointed
Maintenance mode that had to be switched off
the json = array(); solution
and cUrl loopback restrictions (including the vqmod curl loopback workaround ) http://forum.opencart.com/viewtopic.php?f=191&t=146714
All of these solutions didn't seem to work... When i finally found out that I had my VPS access restricted on IP address and removed this restriction the order history update seemed to work fine so I assumed ALL was ok.
Today when I tried to edit an order, the same following error came popping up. So I started going over the forums again for a solution.
While heavily frustrated trying things i bumped in to this strange behaviour. When on the first page of order editing I get the error, but when I select the standard shop... all works fine... I can edit the order exactly how i want... but when i switch the option back to the store the order was placed in... it responds directly with the same error (see attachment).
I'm not sure if there are any other multistore users that are on 2.0.3+ that have shops that are working fine?
Could you think with me? Could it be something with the Cross-Origin Resource Sharing policy? All suggestions are welcome!
Go to Settings, edit your store (not Default),
and on first tab (Genaral), make sure that your SSL URL is set.
If you don't have SSL, then set the same value as Store URL.
Hope this helps.
Probably a cross origin policy issue as you mentioned. I solved this issue on 1.5.6 as well as the crossdomain cookie issue (which has never worked properly to my knowledge on any version) by adding:
xhrFields: { withCredentials: true },
In the AJAX request as well as setting access-control-allow-credentials on the receiving header. The trick here is that for cross origin headers to work this way you need to explicitly declare the URL which is allowed (i.e., Header set Access-Control-Allow-Origin "*" will not work). The next trick is that you don't want to accept these headers from any and every URL.
To work around this, I added something like this to the manual.php controller - which in 2.0+ would be api/order.php (and for cross domain cookie sharing common/header.php as well):
$this->load->model('setting/store');
$allowed[] = trim(HTTP_SERVER,'/');
$allowed[] = trim(HTTPS_SERVER, '/');
$stores = $this->model_setting_store->getStores();
foreach ($stores as $store) {
if ($store['url']) $allowed[] = strtolower(trim($store['url'],'/'));
if ($store['ssl']) $allowed[] = strtolower(trim($store['ssl'],'/'));
}
if (isset($this->request->server['HTTP_REFERER'])) {
$url_parts = parse_url($this->request->server['HTTP_REFERER']);
$origin = strtolower($url_parts['scheme'] . '://' . $url_parts['host']);
if (in_array($origin,$allowed)) {
header("access-control-allow-origin: " . $origin);
header("access-control-allow-credentials: true");
} else {
header("access-control-allow-origin: *");
}
} else {
header("access-control-allow-origin: *");
}
header("access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept");
header("access-control-allow-methods: PUT, GET, POST, DELETE, OPTIONS");
This would basically create an array of all acceptable URLs and if the request is valid it sets the HTTP headers explicitly to allow cookies and session data. This was primarily a fix for cross-domain cookie sharing but I have a feeling it may be helpful for working around the 2.0 api issue as well.
A colleague of me found out the api calls are always done through ssl, all I had to do is add the normal store url in the SSL field in the settings from the store (not the main).
I am working on a C++ windows phone application that uses IXMLHTTPRequest2 to perform HTTP Requests. I have run into a situation in my app where I want to remove one of the HTTP cookies that the server assigned to the session. The cookie is used for authentication, and I want to remove it to force a new logon.
I could not find a method to remove a cookie, and when I tried to overwrite the cookie with a new value, it did not work.
The original value of the cookie was set with the set-cookie header:
Set-Cookie: XYZ=9c2725ec03169f17345525d5f4f58455e445a4a42;Secure;Path=/
I tried to manually inject my own expiring cookie in this format:
XYZ=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;
However, when the next request was sent, it still used the original cookie sent by the server. Is there any way that I can properly accomplish this.
Thanks
Ok, I figured it out. Looks like I was just setting the cookie incorrectly:
XHR_COOKIE xhrCookie = {0};
xhrCookie.pwszUrl = url;
xhrCookie.dwFlags = XHR_COOKIE_IS_SESSION;
xhrCookie.pwszName = L"XYZ";
xhrCookie.pwszValue = L"xyz;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;";
DWORD dwCookieState=0;
m_xhr->SetCookie(&xhrCookie , &dwCookieState)
Is there a way to determine the timezone for a user agent without javasript?
normally, i would execute this snippet of javascript:
<script type="text/javascript" language="JavaScript">
var offset = new Date();
document.write('<input type="hidden" id="clientTzOffset"
name="clientTzOffset" value="' + offset.getTimezoneOffset() + '"/>');
</script>
However, for a lot of mobiles and clients, JS is either not existant or turned off. Is there something clever I can do or am I reduced to "tell me where you are and what timzeone you are in?"
Use both. Have javascript set the default value of a list or text field. The percentage of people without javascript is so small the burden is tiny.
I was going to say "Use the request Date: header" but that's a response header only it seems.
I thought of another solution but it is a little complex. Set up some fake HEAD requests with a max-age: 1 response header to coerce the browser into re-fetching them. You should then receive an if-modified-since header from any modern browser like so:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Just be careful not to send any Last-Modified headers with the first response because
To get best results when sending an If-
Modified-Since header field for cache validation, clients are
advised to use the exact date string received in a previous Last-
Modified header field whenever possible.
Note the "whenever possible" disclaimer. This, and other parts of the header description imply that the client will use its own clock when it doesn't know anything of the servers.
With the right combination of headers this could actually work very well.
EDIT: Tried some tests with FF but couldn't find a valid combination of headers to trigger an if-modified-since in client time. FF only sends the header if it got a last-modified header previously and then it just reflects the value back (even if it isn't a valid date).
Maybe with a server side language you could do an IP lookup, and then determine from their country what timezone they could be in.
I'd imagine this could be problematic, though.
If going down this road, this question (and answers) may be of assistance.
Getting the location from an IP address
I've seen a website where instead of asking what timezone the user was in it simply asked "pick the correct time" and it showed them a list of times. It's a subtle difference from "what timezone are you in" but much easier to understand. Unfortunately I can't find the website anymore