$cookies doesn't represent current state of document.cookie #7631

Closed
amaltson opened this Issue May 29, 2014 · 5 comments
@amaltson

In an $http login call that we make, the resulting header has a Set-Cookie. While the cookie does get set in the browser, i.e. I can see it in document.cookie, it doesn't make it's way to $cookies.

Below is the response header setting the cookie:
response-header-cookie

And here is document.cookie indicating the cookie exists but $cookies doesn't see it.
nothing-in-cookies

The strangest thing is on the next Angular action I take, $cookies has the cookie. The example above is already wrapping the $cookies check in a $timeout to give the browser time to digest.

The workaround right now is to parse document.cookie and set $cookies manually, but this is super hacky.

@btford btford self-assigned this May 30, 2014
@btford btford added this to the Backlog milestone May 30, 2014
@kevinjamesus86

The $cookies service uses $browser.addPollFn to watch for cookie changes ( which runs at 100ms intervals ) and is likely the reason for this behavior. If you increase your $timeout delay to 100ms you will be able to access the cookie from $cookies.

With that said you could use $browser.cookies() directly as it will return a hash of all cookies at the time of the call. If you're used to using the $cookieStore service keep in mind that the former will not deserialize the cookie values for you. I am not sure if the ng team would recommend this but.. yeah, it is an option.

@kevinjamesus86

@amaltson Alternatively, you could register an http interceptor to update the $cookies service with the cookies at the time of the response: https://gist.github.com/kevinjamesus86/ed559abea9e58bfd3d69. At best this will ensure that when you check $cookies in an http callback it'll be up to date.

@btford btford removed the gh: issue label Aug 20, 2014
@jelling
jelling commented Sep 30, 2014

+1 for fixing this

@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
dbcf943
@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
3f89d91
@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
5b5cb7c
@shahata shahata added a commit to shahata/angular.js that referenced this issue Jan 5, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
234e63b
@wilk
wilk commented Jan 9, 2015

Up!

Faced the same problem, solved with $browser.cookies().

@amaltson
amaltson commented Feb 4, 2015

If $browser.cookies() is the new hotness, I'll close off this issue.

@amaltson amaltson closed this Feb 4, 2015
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
072dcd8
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
d1bc67f
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
500349e
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
ad5c182
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
b080151
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata fix($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
67eaae3
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b078df5
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
77d88a4
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
9ecf91e
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b8aa0a4
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
61dbacc
@shahata shahata added a commit that referenced this issue Mar 2, 2015
@shahata @petebacondarwin shahata + petebacondarwin feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
38fbe3e
@hansmaad hansmaad pushed a commit to hansmaad/angular.js that referenced this issue Mar 10, 2015
@shahata shahata + hansmaad feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
e401139
@netman92 netman92 added a commit to netman92/angular.js that referenced this issue Aug 8, 2015
@shahata @netman92 shahata + netman92 feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b5eecdc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment