Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
amaltson opened this issue May 29, 2014 · 6 comments
Closed

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

amaltson opened this issue May 29, 2014 · 6 comments

Comments

@amaltson
Copy link

@amaltson amaltson commented May 29, 2014

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
Copy link

@kevinjamesus86 kevinjamesus86 commented Jul 27, 2014

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
Copy link

@kevinjamesus86 kevinjamesus86 commented Jul 28, 2014

@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
Copy link

@jelling jelling commented Sep 30, 2014

+1 for fixing this

shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
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 angular#6411, angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
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 angular#6411, angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
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 angular#6411, angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Jan 5, 2015
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 angular#6411
Closes angular#7631
@wilk
Copy link

@wilk wilk commented Jan 9, 2015

Up!

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

@amaltson
Copy link
Author

@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 added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
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 angular#6411
Closes angular#7631
shahata added a commit that referenced this issue Mar 2, 2015
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
hansmaad pushed a commit to hansmaad/angular.js that referenced this issue Mar 10, 2015
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 angular#6411
Closes angular#7631
netman92 added a commit to netman92/angular.js that referenced this issue Aug 8, 2015
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 angular#6411
Closes angular#7631
@mkonecny
Copy link

@mkonecny mkonecny commented Oct 15, 2018

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

It's not the new hotness. Just upgraded from Angular 1.3 -> 1.4 and the function no longer exists.

EDIT: Seems this was fixed correctly in Angular 1.4: 38fbe3e so we don't need this $browser.cookies workaround anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.