Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

$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
Labels
component: ngCookies frequency: low needs: more info severity: confusing type: bug
Milestone
Backlog - won't fix

Comments

@amaltson
Copy link

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
@IgorMinar IgorMinar mentioned this issue Jul 26, 2014
Closed
@kevinjamesus86
Copy link

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

@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 commented Sep 30, 2014

+1 for fixing this

@wilk
Copy link

wilk commented Jan 9, 2015

Up!

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

@shahata shahata mentioned this issue Jan 25, 2015
Closed
@amaltson
Copy link
Author

amaltson commented Feb 4, 2015

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

@amaltson amaltson closed this as completed Feb 4, 2015
@petebacondarwin petebacondarwin mentioned this issue Mar 1, 2015
Closed
shahata added a commit that referenced this issue Mar 2, 2015
@shahata @petebacondarwin
feat($cookies): move logic into $cookies and deprecate $cookieStore
38fbe3e 
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
@santoshkt santoshkt mentioned this issue Mar 5, 2015
Closed
hansmaad pushed a commit to hansmaad/angular.js that referenced this issue Mar 10, 2015
@shahata
feat($cookies): move logic into $cookies and deprecate $cookieStore
e401139 
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 pushed a commit to netman92/angular.js that referenced this issue Aug 8, 2015
@shahata @netman92
feat($cookies): move logic into $cookies and deprecate $cookieStore
b5eecdc 
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 commented Oct 15, 2018 •
edited
Loading

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
component: ngCookies frequency: low needs: more info severity: confusing type: bug
Projects
None yet
Milestone
Backlog - won't fix
Development

No branches or pull requests
7 participants
@amaltson @btford @wilk @mkonecny @pkozlowski-opensource @kevinjamesus86 @jelling