PhantomJS

* page.cookies

* page.addCookie({cookie object})

* page.deleteCookie("cookie name")

* page.clearCookies()

 

Those API are specific to the page they are in and, most importantly, THE URL the page is on.

That's how browser work and that's how PhantomJS, an HEADLESS BROWSER, has to work.

In other words: if you are on "github.com" and try to set a cookie for "google.com", it will be rejected.

 

But, there is hope if you want to manipulate cookies directly in the JAR (that means, without caring for a specific page).

 

* phantom.cookiesEnabled

* phantom.cookies

* phantom.addCookie({cookie object})

* phantom.deleteCookie("cookie name")

* phantom.clearCookies()

 

those API allow you to set any cookie you want, before you load a page (or without the need of opening one at all).

If you set a cookie on ".google.com" and than open a page on "www.google.com", that cookie will be picked up.

 

 

Said all this, now about the Session cookies: if you want to "PRESERVE" session cookies, you need to make it yourself.

You can access all the session cookies until they are purged (at shutdown): this means you can collect them, store them (use the "fs" API) and restore them at the next launch.

 

It's simple and it's, most importantly, the correct behaviour for the browser.

 

Session file format change

To put it as simple as possible, the previous format was wrong.

Cookies were stored "per domain", and didn't take into consideration the fact that cookies for ".google.com" will be visible on "www.google.com / translate.google.com / whatever.google.com".

Only the fact that PhantomJS doesn't have an extremely large audience didn't make us look like fools with that implementation: but that needed to be rewritten and that's what I did.

 

The fact that cookies are stored in binary is just a convenience to speed things up: having to write the cookies in a "textual" format would have required to deal with parsing and all sort of stuff that:

- there was no time to deal with

- would have been slower than serializing/deserializing the binary data

 

 

A short remark. I have read this thread and tried to be helpful.

I have spent time debugging code was not mine, only to discover that the issue was in not understanding how session cookie work.

I'm now seeing you guys criticising work you frankly don't get, because "it doesn't behave like before and now my code breaks".

This is not a commercial software: this is open source software.

We make it while going along.

 

Sometimes we get it right, a lot of times we get it wrong.

It's not in our intention to create disruption or "ruin your day".

But it's our freaking time we spend on this stuff: have the mercy to understand that.

And the grace to spend more than a couple of neurons to realize that a change to improve things might break previous code.

We release versions for a reason.

There are some of us dedicating their time to build binary versions to release and create "versions".

 

You don't like a new version? Stick with the previous one.

You want "the new shiny thing in the new version", deal with the fact that there might be changes and things will/can break.

 

Ultimately, the code is there: if you think something is wrong or broken, or you just want to understand "what the heck are we doing",

start your favourite editor and read up.

You might be on to something, and anyone here will praise you for your fix/improvement.

HELP TO MAKE THE PROJECT BETTER if you think we are making mistakes.

Fix code, write tests, write documentation. That is ALL helpful.