Develop Reference

Can I save a cookie and use it on an other page?

[RESOLVED]
I have a little website stored at file:/// with multiple pages with a quiz in each pages. I need to save the results of the quiz in a cookie. When I am changing page, the cookie turn undefined and I don't know how to access the cookie of the previous page. How could I do that ? Is using a cookie the best idea ?
Thank you and have a great day.
Ben
On first page, I put the number 1 in a cookie. When I try to access it on the second page, the cookie is undefined. I would want it to have 1 in it.

No, not directly (because of CORS).
But you can:
Centralize all cookies (cookiepot.com)
When some body visits one of your "share cookie"-sites you redirect him to cookiepot.
Cookiepot redirects the user back with the information you need
This is how Google+Youtube, Stackoverflow+Stackexchange do it. There is no other way except when servers change the information directly with each other.

EDIT: after the quesion owner edited the question, is was discovered that he used a local file.
local files cannot use cookies in most browsers. you can use SessionStorage instead.
ORIGINAL ANSWER
2 pages can use the same cookies as long as they are in the same domain.
for example, website.com/a.html and website.com/b.html can use the same cookies, but otherwebsite.com/c.html wouldn't be able to use that cookie.
are your two pages in the same website?
If they aren't, there it is possible to allow one website to use another website's cookies but I have a feeling that's not the case.

Sure you can save a cookie (document.cookie = 'testcookie=;expires=Thu, 01 Jan 1970 00:00:01 GMT;';) and use it on any other page as long as the pages are on the same domain. This is how you save a cookie on a form submit or any other trigger:
https://codepen.io/hac/pen/oOKOOe

Overwriting HttpOnly cookie by JavaScript? [duplicate]

Say for example I had an application sending the following HTTP headers to set to cookie named "a":
Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1
If I access /example on the server both paths are valid, so I have two cookies named "a"! Since the browser doesn't send any path information, the two cookies cannot be distinguished.
Cookie: a=2; a=1
How should this case be handled? Pick the first one? Create a list with all cookie values? Or should such a case be considered as a developer's mistake?

The answer referring to an article on SitePoint is not entirely complete. Please see RFC 6265 (to be fair, this RFC was released in 2011 after this question was posted, which supersedes previous RFC 2965 from 2000 and RFC 2109 from 1997).
Section 5.4, subsection 2 has this to say:
The user agent SHOULD sort the cookie-list in the following order:
Cookies with longer paths are listed before cookies with shorter paths.
NOTE: Not all user agents sort the cookie-list in this order, but this
order reflects common practice when this document was written, and,
historically, there have been servers that (erroneously) depended on
this order.
There is also this little gem in section 4.2.2:
... servers SHOULD NOT rely upon the serialization order. In
particular, if the Cookie header contains two cookies with the same
name (e.g., that were set with different Path or Domain attributes),
servers SHOULD NOT rely upon the order in which these cookies appear in the header.
In your example request cookie (Cookie: a=2; a=1) note that the cookie set with the path /example (a=2) has a longer path than the one with the path / (a=1) and so it is sent back to you first in line, which matches the recommendation of the spec. Thus you are more or less correct in your assumption that you could select the first value.
Unfortunately the language used in RFCs is extremely specific - the use of the words SHOULD and SHOULD NOT introduce ambiguity in RFCs. These indicate conventions that should be followed, but are not required to be conformant to the spec. While I understand the RFC for this quite well, I haven't done the research to see what real-world clients do; it's possible one or more browsers or other softwares acting as HTTP clients may not send the longest-path cookie (eg: /example) first in the Cookie: header.
If you are in a position to control the value of the cookie and you want to make your solution foolproof, you are best off either:
using a different cookie name to override in certain paths, such as:
Set-cookie: a-global=1;Path=/;Version=1
Set-cookie: a-example=2;Path=/example;Version=1
storing the path you need in the cookie value itself:
Set-cookie: a=1&path=/;Path=/;Version=1
Set-cookie: a=2&path=/example;Path=/example;Version=1
Both of these workarounds require additional logic on the server to pick the desired cookie value, by comparing the requested URL against the list of available cookies. It's not too pretty. It's unfortunate the RFC did not have the foresight to require that a longer path completely overrides a cookie with a shorter path (eg: in your example, you would receive Cookie: a=2 only).

From this article on SitePoint:
If multiple cookies of the same name match a given request URI, one is chosen by the browser.
The more specific the path, the higher the precedence. However precedence based on other attributes, including the domain, is unspecified, and may vary between browsers. This means that if you have set cookies of the same name against “.example.org” and “www.example.org”, you can’t be sure which one will be sent back.
Edit: this information from 2010 appears to be outdated, it seems browsers can now send multiple cookies in return, see answer by #Nate below for details

#user2609094 clarifies the behaviour around paths, so I thought I'd add a quick answer for the behaviour around domains (which is unspecified).
If you create cookies for a domain and subdomain ("foo.example.org" and "example.org") with the same name then the browser will send both cookies, with no indication of which one is which. Additionally, the order does not appear to be based on which domain is more specific. From testing in Google Chrome, the cookies are simply sent in the order they were created - so you can't make any assumptions about which one is which.

There is nothing wrong with having multiple values for the same name... if you want them. You might even embed additional context in the value.
If you don't, then of course different names are a solution if you want both contexts.
The alternative is to send the same cookie name with the same path (and domain) even from the more specific paths. Those set cookie instructions will overwrite the value of that cookie.
Now that you know the most important part (how they work), and that you can accomplish what you need in a few different ways, my answer to your question is: this is a developer issue.

I'm certainly aware of applications which do this extensively using multiple session ids - and seem to work consistently. However I don't know - and have no intention of finding out - if they do so because the browser returns the cookies in a consistent order depending on when they were set / which path they were set for or whether the app tries to match each one to an existing session.
I would strongly recommend that this practice be avoided.
However if you really want to know how the browsers (and apps) handle this scenario, why not build a test rig and try it out.

If you use the Java/Scala framework Play: watch out! If a request contains multiple cookies with the same name, Play will only present 1 of them to your code.

If you need to distinguish them you have to give them different key values.

Is Cookies the best way?

I am using Joomla, and there are 2 Sections/Branches, when the user lands on the home page they will be asked where they wan to go to.
If they choose Section A i want the browser to remember their choice for future, however if they decide for some reason to visit Section B later, i want the browser to replace the Section A with B so that in future B will be remembered.
Is using cookies the right way, if so how could this be done, any help would be much appreciated.

If both section/branches are in same domain (or subdomains) cookies are a good way, but local storage can be a good option too.
The following link can help you to use cookies in Joomla http://blog.tormix.com/joomla/set-and-get-cookies-in-joomla-cms/

Today the moist preferred way is storing inside a localstorage and not inside cookie's
because cookies are sent vs every request and storage is not.
(https://developer.mozilla.org/en/docs/Web/API/Window/localStorage)
Also you can pick one of the libs from this article
And you can use modernizer to be compliant with the old browsers version.

Setcookie("path", "A", 3600*31*365); // Set cookie for about a year.
Echo $_cookie["path"]; // Read cookie
Setcookie("path", "B", 3600*31*365); // Replace the cookie with path B.

js function to go back in browser history to last browsed page of specific domain?

I need the js function to go back in history to the last pages used in a specific domain.
reason: I send people to a subdomain to see specific content-galleries (gallery.mydomain.xyz/#1etc). I need them to return to the last page where they left of from the specific tld (mydomain.xyz/pageX) after having clicked through a number of images/videos there at subdomain...
is this possible? any ideas?
thx!

It's not possible using the built-in browser history, no, because your access to that from JavaScript is close to non-existent.
What you can do instead is save the location you want to take them back to in, say, session storage (use local storage instead if this is in a different window), and then link back to that page.
More about session storage / local storage in the web storage spec, but the short version is that it stores strings in a storage area specific to your origin, so for instance:
localStorage.setItem("last-location", "foo");
...stores "foo" in local storage for your origin, with the key "last-location". You can then use getItem to get it later when you need it:
var lastLocation = localStorage.getItem("last-location");

you could use a simple get/post variable to tell where the user is coming from and store that in a session variable for later use when the user is to be returned. As far as I know you cant access the users browsing history from the browsing client with Javascript as its a violation of the sandbox design but that may have changed recently

thx both of you for the quick answer!
... I kind of see, not being a versatile coder myself. but I get the problem involved. and see session-storage is where I want to look at then...
I will have to make this a coding job given my non-skills here :-}
but now I know what to ask for. thx again.

JavaScript cookie setting used to work and stopped

In a nutshell, I have a web application which used to be able to set cookies just fine, but it no longer works. The really strange thing is I've used Chrome's debugger to follow what's going on, and it makes it all the way to the "document.cookie = " statement fine.
Further, I haven't changed anything except the content of the cookie (adding more information). I haven't modified the cookie setting logic at all, or even the parameters.
Here's the most recent version of my application: http://asmor.com/scripts/tsrand/alpha/
The relevant bit is lines 147-149, http://asmor.com/scripts/tsrand/alpha/init.js
cookie=JSON.stringify(opt)
log("Cookie: "+cookie);
$.cookie(cookieName, cookie, { expires: 365 });
opt is an object I'm using to store form element values. I convert the object into a JSON string and then store it. Here's an example of what cookie contains in this version of the program:
{"diseaseSelect":".5","soloGame":"checkbox:false","showLog":"checkbox:true","min_Setting":"0","max_Setting":"1","cardBarrowsdale":"Maybe","cardDoomgate":"Maybe","cardDragonspire":"Maybe","cardDreadwatch":"Maybe","cardFeaynSwamp":"Maybe","cardGrimhold":"Maybe","cardRegianCove":"Maybe","min_Thunderstone":"1","max_Thunderstone":"1","cardStoneofAgony":"Maybe","cardStoneofAvarice":"Maybe","cardStoneofMystery":"Maybe","cardStoneofScorn":"Maybe","cardStoneofTerror":"Maybe","min_Monster":"3","max_Monster":"3","cardAbyssal":"Maybe","cardAbyssalThunderspawn":"Maybe","cardBanditHumanoid":"Maybe","cardCultistHumanoid":"Maybe","cardDarkEnchanted":"Maybe","cardDoomknightHumanoid":"Maybe","cardDragon":"Maybe","cardElementalFire":"Maybe","cardElementalNature":"Maybe","cardElementalPain":"Maybe","cardEnchanted":"Maybe","cardEvilDruidHumanoid":"Maybe","cardGiant":"Maybe","cardGolem":"Maybe","cardHorde":"Maybe","cardHumanoid":"Maybe","cardHydraDragon":"Maybe","cardOoze":"Maybe","cardOrcHumanoid":"Maybe","cardTheSwarm":"Maybe","cardUndeadDoom":"Maybe","cardUndeadLich":"Maybe","cardUndeadPlague":"Maybe","cardUndeadSpirit":"Maybe","cardUndeadStormwraith":"Maybe","min_Guardian":"0","max_Guardian":"1","cardDarkChampion":"Maybe","cardDeathSentinel":"Maybe","cardGuardianofNight":"Maybe","cardGuardianofTorment":"Maybe","cardUnholyGuardian":"Maybe","min_Trap":"0","max_Trap":"1","cardTrapDeath":"Maybe","cardTrapDire":"Maybe","cardTrapDraconic":"Maybe","min_Treasure":"0","max_Treasure":"1","cardAmuletTreasure":"Maybe","cardFigurineTreasure":"Maybe","cardUlbricksTreasure":"Maybe","min_Hero":"4","max_Hero":"4","cardAmazon":"Maybe","cardBelzur":"Maybe","cardBlind":"Maybe","cardCabal":"Maybe","cardChalice":"Maybe","cardChulian":"Maybe","cardClan":"Maybe","cardDeep":"Maybe","cardDiin":"Maybe","cardDrunari":"Maybe","cardDivine":"Maybe","cardDwarf":"Maybe","cardElf":"Maybe","cardEvoker":"Maybe","cardFeayn":"Maybe","cardFlame":"Maybe","cardGangland":"Maybe","cardGohlen":"Maybe","cardGorinth":"Maybe","cardHalf-Orc":"Maybe","cardLorigg":"Maybe","cardOutlands":"Maybe","cardPhalanx":"Maybe","cardRedblade":"Maybe","cardRegian":"Maybe","cardRunespawn":"Maybe","cardSelurin":"Maybe","cardSidhe":"Maybe","cardSlynn":"Maybe","cardStoneguard":"Maybe","cardTempest":"Maybe","cardTerakian":"Maybe","cardTholis":"Maybe","cardThyrian":"Maybe","cardToryn":"Maybe","cardVerdan":"Maybe","cardVeteran":"Maybe","min_Village":"8","max_Village":"8","cardAmbrosia":"Maybe","cardAmuletofPower":"Maybe","cardArcaneEnergies":"Maybe","cardBanish":"Maybe","cardBarkeep":"Maybe","cardBattleFury":"Maybe","cardBlacksmith":"Maybe","cardBlessedHammer":"Maybe","cardBluefireStaff":"Maybe","cardBorderGuard":"Maybe","cardBurntOffering":"Maybe","cardChieftansDrum":"Maybe","cardClaymore":"Maybe","cardCreepingDeath":"Maybe","cardCursedMace":"Maybe","cardCyclone":"Maybe","cardDivineStaff":"Maybe","cardDoomgateSquire":"Maybe","cardFeast":"Maybe","cardFireball":"Maybe","cardFlamingSword":"Maybe","cardFlaskofOil":"Maybe","cardForesightElixir":"Maybe","cardFortuneTeller":"Maybe","cardFrostBolt":"Maybe","cardFrostGiantAxe":"Maybe","cardGlowberries":"Maybe","cardGoodberries":"Maybe","cardGreedBlade":"Maybe","cardGuardianBlade":"Maybe","cardGuide":"Maybe","cardHatchet":"Maybe","cardIllusoryBlade":"Maybe","cardLantern":"Maybe","cardLightstoneGem":"Maybe","cardMagiStaff":"Maybe","cardMagicMissile":"Maybe","cardMagicalAura":"Maybe","cardPawnbroker":"Maybe","cardPiousChampion":"Maybe","cardPolearm":"Maybe","cardPolymorph":"Maybe","cardQuartermaster":"Maybe","cardRecurveBow":"Maybe","cardSage":"Maybe","cardScout":"Maybe","cardShortBow":"Maybe","cardShortSword":"Maybe","cardSilverstorm":"Maybe","cardSkullbreaker":"Maybe","cardSoulGem":"Maybe","cardSoulJar":"Maybe","cardSpear":"Maybe","cardSpiritBlast":"Maybe","cardSpiritHunter":"Maybe","cardSpoiledFood":"Maybe","cardTavernBrawl":"Maybe","cardTaxCollector":"Maybe","cardThunderRing":"Maybe","cardTorynGauntlet":"Maybe","cardTownGuard":"Maybe","cardTrader":"Maybe","cardTrainer":"Maybe","cardWarhammer":"Maybe"}
Now, here's the oldest backed-up copy I have: http://asmor.com/scripts/tsrand/backup/2010-09-13/dev/
This copy still works.
Here's the cookie-setting logic from that copy, lines 130-132 http://asmor.com/scripts/tsrand/backup/2010-09-13/dev/scripts/init.js
cookie=JSON.stringify(opt)
log("Cookie: "+cookie);
$.cookie(cookieName, cookie, { expires: 365 });
And an example of what the cookie for that one contains:
{"guardianSelect":".5","trapSelect":"1","monstersSelect":"3","heroesSelect":"4","villageSelect":"8","soloGame":"checkbox:false","useConditions":"checkbox:true","showLog":"checkbox:true","setBase":"checkbox:false","setPromo":"checkbox:true","setWrathOfTheElements":"checkbox:false","cardAbyssal":"Maybe","cardDoomknightHumanoid":"Maybe","cardDragon":"Maybe","cardElementalNature":"Maybe","cardElementalPain":"Maybe","cardEnchanted":"Maybe","cardGolem":"Maybe","cardHorde":"Maybe","cardHumanoid":"Maybe","cardOoze":"Maybe","cardUndeadDoom":"Maybe","cardUndeadSpirit":"Maybe","cardDarkChampion":"Maybe","cardDeathSentinel":"Maybe","cardTrapDeath":"Maybe","cardTrapDire":"Maybe","cardAmazon":"Maybe","cardBlind":"Maybe","cardChalice":"Maybe","cardClan":"Maybe","cardDiin":"Maybe","cardDivine":"Maybe","cardDwarf":"Maybe","cardElf":"Maybe","cardFeayn":"Maybe","cardGangland":"Maybe","cardGohlen":"Maybe","cardLorigg":"Maybe","cardOutlands":"Maybe","cardRedblade":"Maybe","cardRegian":"Maybe","cardRunespawn":"Maybe","cardSelurin":"Maybe","cardThyrian":"Maybe","cardToryn":"Maybe","cardAmbrosia":"Maybe","cardAmuletofPower":"Maybe","cardArcaneEnergies":"Maybe","cardBanish":"Maybe","cardBarkeep":"Maybe","cardBattleFury":"Maybe","cardBlacksmith":"Maybe","cardClaymore":"Maybe","cardCreepingDeath":"Maybe","cardCursedMace":"Maybe","cardFeast":"Maybe","cardFireball":"Maybe","cardFlamingSword":"Maybe","cardForesightElixir":"Maybe","cardGoodberries":"Maybe","cardHatchet":"Maybe","cardIllusoryBlade":"Maybe","cardLantern":"Maybe","cardLightstoneGem":"Maybe","cardMagiStaff":"Maybe","cardMagicMissile":"Maybe","cardMagicalAura":"Maybe","cardPawnbroker":"Maybe","cardPolearm":"Maybe","cardSage":"Maybe","cardShortBow":"Maybe","cardShortSword":"Maybe","cardSpear":"Maybe","cardTavernBrawl":"Maybe","cardTaxCollector":"Maybe","cardTownGuard":"Maybe","cardTrainer":"Maybe","cardWarhammer":"Maybe"}
I'm using libraries for the JSON and for setting/getting the cookie. Both that early version and the latest use the exact same versions of the exact same libraries.
The only thing I can think of is that the cookie has gotten a bit more than twice as long. Before URI encoding, we're talking 4000 characters vs. 1800 characters. Also, I URI encoded the more recent cookie and manually set it myself, and the browser accepted it just fine, and my program loaded it just fine.
I'm completely out of ideas here. Help!

You should really store all this data in a session on the server if possible, rather than having a massive cookie. Then you can simply request data via AJAX or embed it in each page request.
Browsers are only required to provide 4KB of space per cookie, so if you're over that there's a chance it might not be stored.

4096-byte limit; otherwise entire cookie is discarded by IE.
http://support.microsoft.com/kb/306070