Setting cookie attributes in $cookieStore #2459

Closed
wants to merge 6 commits into
from

Conversation

@alonbardavid
Contributor

alonbardavid commented Apr 20, 2013

As a response to issues: #1786,#950,#1918,#1320
This PR enables setting a cookie's path and expires attributes using the $cookieStore service.
$cookies was not changed, since it's API is too strict, I could find no way to implement it without causing breaking changes, or using some terrible hacks.
I would suggest adding a new service to the module to support more advanced features (such as Json $watch expression, which should be more useful then binding the $cookies object directly), but this would probably require a bit of research regarding use cases.

Some things to note regarding the implementation:

  • urlroot (karma property) was added to all unit tests - to facilitate testing of different cookie path
  • Backward incompatible change (bad fixing a bad behaviour):
    delete cookie now deletes cookies set with a path other then / (or baseHref)
    that is before the fix, if you had a cookie set on path /karma (if it was added by the server for instance),
    you would be able to see it, but deleting it will fail silently (and will not delete)
    delete cookie now deletes duplicate cookies with the same name (if they have different paths)
  • Due to the fact that no browser allows inspecting the Path and Expiration date of a cookie, I chose to add a private _setCookie function inside the $browser module
    which I override in unit tests. Not the most elegent solution, but the only other way to check Expiration is to mock the document object and change how document.cookie works, and that would have taken me too long for very little benefit.

Design decisions:

  • to change the path and/or expiration date of a cookie, you can pass an options object as the third argument to cookies(name,value)
    the options object can override Path and Expires when adding a value, all other options variables are ignored (but are allowed, I.E. no validation is made).
    You can pass either path, expires,none or both.
  • the path option is checked to be a string and be partial to window.location, otherwise, the default path is used. (warning is logged)
  • the expires option is checked to be a Date and in the future, otherwise no expiration is set. (warning is logged)
  • at the moment no support for non-Date expires is supported (for instance such as maxAge, or a number to indicate number of millesconds for cookie to last)
  • you can now delete a cookie on a specific path by calling cookie(name,undefined,options), with options containing path
  • only the $cookieStore service will support putting cookies with different path/expiration (as well as deleting certain paths.
    this is to support backward compatability with $cookies.

Notes:
if the value passed to browser.cookies is not a String, it fails silently.

This is my first time contributing here (and on a Major open source project), I hope this can be incorporated.
I'm more than happy to make changes if something is wrong, so please let me know.

alonbardavid added some commits Apr 20, 2013

feat(ngCookies): support passing path/expires attributes to cookies
$cookieStore service had no way to set cookie attributes (such as expires).
The api for $cookieStore.put and $cookieStore.remove now has a third argument-
options,which allows setting cookie attributes, or deleting cookies under a
specific path.
- to change the path and/or expiration date of a cookie, you can pass an
  options object as the third argument to cookies(name,value).
  the options object can override Path and Expires when adding a value.
  You can pass either path, expires,none or both.
- the path option is checked to be a string and be partial to window.location
  otherwise, the default path is used. (warning is logged)
- the expires option is checked to be a Date and in the future,
  otherwise no expiration is set. (warning is logged)
- you can now delete a cookie on a specific path by calling
  cookie(name,undefined,{path:x})

The $cookie service remains unchanged since supporting cookie attributes
would mean serious backward comptability issues.
Foundations were put in place to make supporting $cookie easier.
GENERIC TEST CHANGE:
To support checking cookie path, all unit-tests now run on path "/karma/tests"
Documentation was updated for both $cookie and $cookieStore with examples.

closes	#1786, #1320
BREAKING CHANGE: As part of the change, deleting a cookie  now deletes
   cookies set in multiple paths (and duplicate cookies if exists).
   Previously only cookies set in the / path were deleted.
   Since it is not intutive, if this change breaks someones code, it is
   probably as an accidental side-effect.
   It is reasonable to assume that most people actually wanted to delete the
   cookie even if it wasn't set in the same path (since they can see it).
   So while this is a breaking change, it fixes bad behaviour.
   If needed, you can delete the cookie in a specific path using $cookieStore.
@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 20, 2013

Contributor

I also signed the "Contributor License Agreement" electronically, I think (it redirect to nothing :/) .
Using the email used here.

Contributor

alonbardavid commented Apr 20, 2013

I also signed the "Contributor License Agreement" electronically, I think (it redirect to nothing :/) .
Using the email used here.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 22, 2013

Member

PR Checklist (Minor Feature)

  • Contributor signed CLA now or in the past (if you just signed, leave a comment here with your real name for cross reference)
  • Feature improves existing core functionality
  • API is compatible with existing Angular apis and relevant standards (if applicable)
  • PR doesn't contain a breaking change
  • PR contains unit tests
  • PR contains e2e tests (if suitable)
  • PR contains documentation update
  • PR passes all tests on Travis (sanity)
  • PR passes all tests on ci.angularjs.org (cross-browser compatibility)
  • PR is rebased against recent master
  • PR is squashed into one commit per logical change
  • PR's commit messages are descriptive and allows us to autogenerate release notes (required commit message format)
  • All changes requested in review have been implemented
Member

petebacondarwin commented Apr 22, 2013

PR Checklist (Minor Feature)

  • Contributor signed CLA now or in the past (if you just signed, leave a comment here with your real name for cross reference)
  • Feature improves existing core functionality
  • API is compatible with existing Angular apis and relevant standards (if applicable)
  • PR doesn't contain a breaking change
  • PR contains unit tests
  • PR contains e2e tests (if suitable)
  • PR contains documentation update
  • PR passes all tests on Travis (sanity)
  • PR passes all tests on ci.angularjs.org (cross-browser compatibility)
  • PR is rebased against recent master
  • PR is squashed into one commit per logical change
  • PR's commit messages are descriptive and allows us to autogenerate release notes (required commit message format)
  • All changes requested in review have been implemented
@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 22, 2013

Member

Internet Explorer 8 & 9 don't like this: http://ci.angularjs.org/job/angular.js-pete/90/

Member

petebacondarwin commented Apr 22, 2013

Internet Explorer 8 & 9 don't like this: http://ci.angularjs.org/job/angular.js-pete/90/

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 22, 2013

Member

By the way, you appear to have modified all functions to have a space between function and (), which makes it look like you have far more changes than there really are. I suspect that you didn't purposefully do this for some idealistic aim, but that perhaps your editor did it for you?
For consistency with the rest of the code base I would suggest you revert that formatting in the PR.

Member

petebacondarwin commented Apr 22, 2013

By the way, you appear to have modified all functions to have a space between function and (), which makes it look like you have far more changes than there really are. I suspect that you didn't purposefully do this for some idealistic aim, but that perhaps your editor did it for you?
For consistency with the rest of the code base I would suggest you revert that formatting in the PR.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 22, 2013

Member

Can you explain why you have to expose and mock _setCookie in the service rather than simply injecting document and accessing document[0].cookie in the specs?

Member

petebacondarwin commented Apr 22, 2013

Can you explain why you have to expose and mock _setCookie in the service rather than simply injecting document and accessing document[0].cookie in the specs?

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 22, 2013

Contributor

Function spaces- I suspect the editor did that, I've hopefully reverted that in the following commit.

the problem with accessing document.cookie is that you can't read the Path or Expiration date of a cookie using javascript. So I couldn't have verified that path and expiration was done properly. That's why I need to capture the calls before they reach document.cookie (or mock document.cookie itself, which is a lot of work for little gain).

For example, if I set document.cookie = "cookie=numnum;path=/;expiration=111" when I read document.cookie, I'll get "cookie=numnum".

In regards to why injecting a mock document isn't easy, it's mostly because the tests are already using document, and I would need to mock all the APIs that are used (or alternatively use something like harmony-proxies, which don't work on all browsers).

I've fixed the IE issues that appeared on the tests, however for some bizzare reason, my IE suite get stuck at test 749, and I'm unable at the moment to complete a full suite on IE. since I haven't touched those tests, I'm mostly sure it works (and the fact they didn't appear on the cross-browser hudson also raises my hopes here).

Contributor

alonbardavid commented Apr 22, 2013

Function spaces- I suspect the editor did that, I've hopefully reverted that in the following commit.

the problem with accessing document.cookie is that you can't read the Path or Expiration date of a cookie using javascript. So I couldn't have verified that path and expiration was done properly. That's why I need to capture the calls before they reach document.cookie (or mock document.cookie itself, which is a lot of work for little gain).

For example, if I set document.cookie = "cookie=numnum;path=/;expiration=111" when I read document.cookie, I'll get "cookie=numnum".

In regards to why injecting a mock document isn't easy, it's mostly because the tests are already using document, and I would need to mock all the APIs that are used (or alternatively use something like harmony-proxies, which don't work on all browsers).

I've fixed the IE issues that appeared on the tests, however for some bizzare reason, my IE suite get stuck at test 749, and I'm unable at the moment to complete a full suite on IE. since I haven't touched those tests, I'm mostly sure it works (and the fact they didn't appear on the cross-browser hudson also raises my hopes here).

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 22, 2013

Contributor

Can I ask why "PR is squashed into one commit per logical change" and "PR's commit messages are descriptive" are not checked, did I miss something?

Contributor

alonbardavid commented Apr 22, 2013

Can I ask why "PR is squashed into one commit per logical change" and "PR's commit messages are descriptive" are not checked, did I miss something?

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 25, 2013

Member

@Illniyar -
Thanks for working on the PR.

To answer your question about the tasks:
Two of your four commits are not in the correct format and in any case they should probably be squashed into the other two commits.

I would like to look at the mocking issue a bit further because I don't like the idea of creating backdoors just for testing here. I'll give it a go on with IE on my machine.

Member

petebacondarwin commented Apr 25, 2013

@Illniyar -
Thanks for working on the PR.

To answer your question about the tasks:
Two of your four commits are not in the correct format and in any case they should probably be squashed into the other two commits.

I would like to look at the mocking issue a bit further because I don't like the idea of creating backdoors just for testing here. I'll give it a go on with IE on my machine.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 26, 2013

Contributor

What messages do you put for commits that fix regressions in previous commits? how do you "squash" two commits?

In regards to mocking cookies, what browser support is needed? I can think of a way of doing it, but I need getter/setter support, and I'm not sure what browsers does angular.js need to support (including version numbers for firefox/chrome etc...).
The main problem now is that cookie doesn't work like a normal field, there's no way to mock it without getter/setter support, and if there's one browser that it is tested on and doesn't have such support the tests will fail.

Contributor

alonbardavid commented Apr 26, 2013

What messages do you put for commits that fix regressions in previous commits? how do you "squash" two commits?

In regards to mocking cookies, what browser support is needed? I can think of a way of doing it, but I need getter/setter support, and I'm not sure what browsers does angular.js need to support (including version numbers for firefox/chrome etc...).
The main problem now is that cookie doesn't work like a normal field, there's no way to mock it without getter/setter support, and if there's one browser that it is tested on and doesn't have such support the tests will fail.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 26, 2013

Contributor

Thank you pkozlowski-opensource. I'm not really sure how to squash things now though, should a new branch be created with a new PR? I can't see a way to squash commits on the same branch/repository you are currently working on.

Contributor

alonbardavid commented Apr 26, 2013

Thank you pkozlowski-opensource. I'm not really sure how to squash things now though, should a new branch be created with a new PR? I can't see a way to squash commits on the same branch/repository you are currently working on.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 26, 2013

Contributor

I've commited a fix that will remove the _setCookie backdoor. Hopefully this should work in: IE8+,FF4+,Chrome and Opera12+.

Contributor

alonbardavid commented Apr 26, 2013

I've commited a fix that will remove the _setCookie backdoor. Hopefully this should work in: IE8+,FF4+,Chrome and Opera12+.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 26, 2013

Member

@Illniyar - don't worry about squashing. I can rebase if and when we merge.

Member

petebacondarwin commented Apr 26, 2013

@Illniyar - don't worry about squashing. I can rebase if and when we merge.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Apr 26, 2013

Member

@Illniyar - I am having some issues with this:

http://plnkr.co/edit/6RuykjI6U1AJec0GMwPE?p=preview

It doesn't seem to actually store the cookie in the browser.

Moreover, my understanding is that you remove a cookie from the browser by setting its expiration value to now. You are not doing this.

Any thoughts?

Member

petebacondarwin commented Apr 26, 2013

@Illniyar - I am having some issues with this:

http://plnkr.co/edit/6RuykjI6U1AJec0GMwPE?p=preview

It doesn't seem to actually store the cookie in the browser.

Moreover, my understanding is that you remove a cookie from the browser by setting its expiration value to now. You are not doing this.

Any thoughts?

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Apr 26, 2013

Contributor

I'm not sure what is going on there. If I take the exact same code and put it on directly on a server, it works. Something in Plunker is not working properly, probably there is some kind of permission issue that block the cookie from being set,maybe something to do with the iFrame?

In regards to removing cookie, we set the date to "expires=Thu, 01 Jan 1970 00:00:00 GMT" in all places where we try to delete the cookie, I'm not sure what your seeing that is different.

Contributor

alonbardavid commented Apr 26, 2013

I'm not sure what is going on there. If I take the exact same code and put it on directly on a server, it works. Something in Plunker is not working properly, probably there is some kind of permission issue that block the cookie from being set,maybe something to do with the iFrame?

In regards to removing cookie, we set the date to "expires=Thu, 01 Jan 1970 00:00:00 GMT" in all places where we try to delete the cookie, I'm not sure what your seeing that is different.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 1, 2013

Contributor

any news here?

Contributor

alonbardavid commented May 1, 2013

any news here?

@karlfreeman

This comment has been minimized.

Show comment Hide comment
@karlfreeman

karlfreeman May 1, 2013

Would love to see this be pulled in! Thanks for the request @Illniyar 👍

Would love to see this be pulled in! Thanks for the request @Illniyar 👍

@karlfreeman

This comment has been minimized.

Show comment Hide comment
@karlfreeman

karlfreeman May 1, 2013

@Illniyar Have you considered also adding secure to the cookie store?

@Illniyar Have you considered also adding secure to the cookie store?

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 1, 2013

Contributor

It should be relatively easy to add (along with domain specific cookies ) as the additional options argument provides a lot of lieniency. However there were several reasons why I didn't:

  1. There were no issues open for this (or for adding domain).
  2. I did not want to overload a single commit with too much functionality.
  3. The testing for this might require quite a bit of effort.
Contributor

alonbardavid commented May 1, 2013

It should be relatively easy to add (along with domain specific cookies ) as the additional options argument provides a lot of lieniency. However there were several reasons why I didn't:

  1. There were no issues open for this (or for adding domain).
  2. I did not want to overload a single commit with too much functionality.
  3. The testing for this might require quite a bit of effort.
@karlfreeman

This comment has been minimized.

Show comment Hide comment
@karlfreeman

karlfreeman May 1, 2013

I guess we need to hear from @petebacondarwin about how much $cookieStore should do. Would be great to have feature parity with other js cookie libs.

I guess we need to hear from @petebacondarwin about how much $cookieStore should do. Would be great to have feature parity with other js cookie libs.

@karlfreeman

This comment has been minimized.

Show comment Hide comment
@karlfreeman

karlfreeman May 1, 2013

#950 does mentions a couple things like secure

#950 does mentions a couple things like secure

@IgorMinar

This comment has been minimized.

Show comment Hide comment
@IgorMinar

IgorMinar May 7, 2013

LGTM for this commit. @petebacondarwin can you merge it in please?

LGTM for this commit. @petebacondarwin can you merge it in please?

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin May 8, 2013

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 8, 2013

Owner

Sorry about that, in retrospect, I should probably have made two different pull-requests/branches. this commit was commited on top of the other cookie changes (and not the other way around).

Owner

alonbardavid replied May 8, 2013

Sorry about that, in retrospect, I should probably have made two different pull-requests/branches. this commit was commited on top of the other cookie changes (and not the other way around).

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin May 8, 2013

@IgorMinar

This comment has been minimized.

Show comment Hide comment
@IgorMinar

IgorMinar May 7, 2013

Owner

I looked over the commit a4ed23c and I like the direction, but it still needs some major refactoring:

  • the use of $cookieOptionHash is really hackish, I think that we should make it possible to set the option via $cookies service. How about $cookies.$set(name, value, options) or $cookies(name, value, options) both are backwards compatible.
  • I'd like to move all of the cookie related code out of $browser into the angular-cookies module. long time go other stuff depended on $browser, but currently cookies is the last major piece that holds us from killing $browser. This change could happen as part of this refactoring (maybe as a separate commit though).

What do you think about these two big changes? Would you be up for addressing them?

If you sign up for the $browser refactoring and are capable of making the changes in a timely manner, I'll make sure that this change lands in 1.2 (we'd like to feature freeze 1.1.x within a week).

Owner

IgorMinar commented May 7, 2013

I looked over the commit a4ed23c and I like the direction, but it still needs some major refactoring:

  • the use of $cookieOptionHash is really hackish, I think that we should make it possible to set the option via $cookies service. How about $cookies.$set(name, value, options) or $cookies(name, value, options) both are backwards compatible.
  • I'd like to move all of the cookie related code out of $browser into the angular-cookies module. long time go other stuff depended on $browser, but currently cookies is the last major piece that holds us from killing $browser. This change could happen as part of this refactoring (maybe as a separate commit though).

What do you think about these two big changes? Would you be up for addressing them?

If you sign up for the $browser refactoring and are capable of making the changes in a timely manner, I'll make sure that this change lands in 1.2 (we'd like to feature freeze 1.1.x within a week).

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 8, 2013

Contributor

The $cookies service (as opposed to the $cookieStore service) was appearently desgined to work as a hashmap, I.E. people might use the cookies hashmap directly (see the example I added to the docs to see how it might be used).
Which means that adding any variable to it will cause backward incompatability with anyone who iterates through the entire hashmap.
Since it is returned directly by the factory, we also can't add multiple functions to the $cookie service (as opposed to the $cookieStore service).

I didn't consider returning $cookies as a function, I can't think of a reason why it'll break backward compatability, can you? if not, then it should be done.

it shouldn't be a problem moving the cookies part out of $browser.

I'd be happy to refactor both (assuming $cookies as a function doesn't break compatability).

Considering someone might be using the $browser (and $browser.cookies) directly, shouldn't there be a deprecation period?

Contributor

alonbardavid commented May 8, 2013

The $cookies service (as opposed to the $cookieStore service) was appearently desgined to work as a hashmap, I.E. people might use the cookies hashmap directly (see the example I added to the docs to see how it might be used).
Which means that adding any variable to it will cause backward incompatability with anyone who iterates through the entire hashmap.
Since it is returned directly by the factory, we also can't add multiple functions to the $cookie service (as opposed to the $cookieStore service).

I didn't consider returning $cookies as a function, I can't think of a reason why it'll break backward compatability, can you? if not, then it should be done.

it shouldn't be a problem moving the cookies part out of $browser.

I'd be happy to refactor both (assuming $cookies as a function doesn't break compatability).

Considering someone might be using the $browser (and $browser.cookies) directly, shouldn't there be a deprecation period?

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 8, 2013

Contributor

Just considered a backward compatability issue with $cookies as a function.
if someone bind $cookies directly (for instance using ng-repeat), then if it's a function, it will not get dirty once we change the function's keys.

how to refactor this not very modular implementation depends mostly on how it's used, and what backward compatability we can break.

Contributor

alonbardavid commented May 8, 2013

Just considered a backward compatability issue with $cookies as a function.
if someone bind $cookies directly (for instance using ng-repeat), then if it's a function, it will not get dirty once we change the function's keys.

how to refactor this not very modular implementation depends mostly on how it's used, and what backward compatability we can break.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin May 8, 2013

Member

Merged in 8efadf8 feat($cookieStore): $cookieStore.get now parses blank string as blank as cf4729f and 1240641.

Member

petebacondarwin commented May 8, 2013

Merged in 8efadf8 feat($cookieStore): $cookieStore.get now parses blank string as blank as cf4729f and 1240641.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid May 12, 2013

Contributor

I can get this done in a few days, but I would really like to know how you want the API (and what backward compatability issues) too look like before I start.

Contributor

alonbardavid commented May 12, 2013

I can get this done in a few days, but I would really like to know how you want the API (and what backward compatability issues) too look like before I start.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Jun 19, 2013

Contributor

So a month now since the last comment here.
Unless you have a better idea, I will work on getting $cookies to be a function (thereby breaking compatability with anyone using $cookies directly as a persistable hashmap).
Hopefully we can get this committed soon, I would really like to see this in (I'm using it in my own programs)

Contributor

alonbardavid commented Jun 19, 2013

So a month now since the last comment here.
Unless you have a better idea, I will work on getting $cookies to be a function (thereby breaking compatability with anyone using $cookies directly as a persistable hashmap).
Hopefully we can get this committed soon, I would really like to see this in (I'm using it in my own programs)

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Jun 19, 2013

Contributor

I'm having a bit of trouble with running tests after I've updated the repository to the new master. Seems like Bower was added, and I'm missing something, am I supposed to run some command that will create /componenets/jquery ?

Contributor

alonbardavid commented Jun 19, 2013

I'm having a bit of trouble with running tests after I've updated the repository to the new master. Seems like Bower was added, and I'm missing something, am I supposed to run some command that will create /componenets/jquery ?

@mike-spainhower

This comment has been minimized.

Show comment Hide comment
@mike-spainhower

mike-spainhower Jun 20, 2013

You are probably looking for

# bower install

You are probably looking for

# bower install
@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Jun 20, 2013

Contributor

Yeah, that was it (along with some nasty Windows only issues bower has), thanks.

I've merged the latest changes. I'll work on getting rid of $browser next.

Contributor

alonbardavid commented Jun 20, 2013

Yeah, that was it (along with some nasty Windows only issues bower has), thanks.

I've merged the latest changes. I'll work on getting rid of $browser next.

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Jun 21, 2013

Member

grunt package should run bower install automatically.
On Windows you must run as an administrator to get the symlinks to work for docs generation and e2e testing

Member

petebacondarwin commented Jun 21, 2013

grunt package should run bower install automatically.
On Windows you must run as an administrator to get the symlinks to work for docs generation and e2e testing

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Feb 12, 2014

Contributor

bitrot?

Contributor

alonbardavid commented Feb 12, 2014

bitrot?

@caitp

This comment has been minimized.

Show comment Hide comment
@caitp

caitp Feb 12, 2014

Contributor

In need of rebase

Contributor

caitp commented Feb 12, 2014

In need of rebase

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Feb 12, 2014

Contributor

Well most of the changes are quite contained, and from a brief look it doesn't appear like there were serious changes made to $cookies or $browser since this was made, so I'm not foreseeing a difficult merge.

But without having a sense of what version it can go in, I'm not very eager to merge it only to have to remerge it again on the next version.

Contributor

alonbardavid commented Feb 12, 2014

Well most of the changes are quite contained, and from a brief look it doesn't appear like there were serious changes made to $cookies or $browser since this was made, so I'm not foreseeing a difficult merge.

But without having a sense of what version it can go in, I'm not very eager to merge it only to have to remerge it again on the next version.

@caitp

This comment has been minimized.

Show comment Hide comment
@caitp

caitp Feb 12, 2014

Contributor

There are merge conflicts currently, and a lot of stuff that really doesn't belong in the patch in the first place, it's asking a lot to get the person who wants to check it in to deal with the merge conflicts for you. Please be kind and rewind

Contributor

caitp commented Feb 12, 2014

There are merge conflicts currently, and a lot of stuff that really doesn't belong in the patch in the first place, it's asking a lot to get the person who wants to check it in to deal with the merge conflicts for you. Please be kind and rewind

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Feb 13, 2014

Contributor

What stuff does not belong in the patch?

I'm not asking anyone to merge the conflicts, I'm asking to know that if I do I won't need to do it again for the next major version that passes this patch by.

Contributor

alonbardavid commented Feb 13, 2014

What stuff does not belong in the patch?

I'm not asking anyone to merge the conflicts, I'm asking to know that if I do I won't need to do it again for the next major version that passes this patch by.

@caitp

This comment has been minimized.

Show comment Hide comment
@caitp

caitp Feb 13, 2014

Contributor

All of the unnecessary whitespace changes, and changes to the karma configs.

Anyways, I don't think we can promise to merge this, right now it's unmerge-able and very difficult to review. If you make that easier for us by removing unneeded stuff from the diff, that will help a lot.

Contributor

caitp commented Feb 13, 2014

All of the unnecessary whitespace changes, and changes to the karma configs.

Anyways, I don't think we can promise to merge this, right now it's unmerge-able and very difficult to review. If you make that easier for us by removing unneeded stuff from the diff, that will help a lot.

@alonbardavid

This comment has been minimized.

Show comment Hide comment
@alonbardavid

alonbardavid Feb 13, 2014

Contributor

From what I recall, the white space changes were fixed already.
Karma config was required in order to test path specific cookies in e2e checks (or at least I wasn't able to find a different way to do it back then).

Contributor

alonbardavid commented Feb 13, 2014

From what I recall, the white space changes were fixed already.
Karma config was required in order to test path specific cookies in e2e checks (or at least I wasn't able to find a different way to do it back then).

@caitp

This comment has been minimized.

Show comment Hide comment
@caitp

caitp Feb 13, 2014

Contributor

No, the 2-space indentation has been replaced with 4-space indentation, which makes the unified diff much harder to review. With whitespace disabled it's not so bad, but the style does need to be fixed up.

Example/e2e tests: It's all protractor now so those would need to be updated to use the new format. Finally, all of the e2e tests run within the context of the docs app (currently), no changes are necessary to the karma config to make those work. You can see a bunch of how this looks at #6232 ... actually thats a bad example since julie already merged ptor example conversions, so lemmec... 7aef2d5 that's a better example... However once the dgeni migration happens, it will prpbably need to change more.

Contributor

caitp commented Feb 13, 2014

No, the 2-space indentation has been replaced with 4-space indentation, which makes the unified diff much harder to review. With whitespace disabled it's not so bad, but the style does need to be fixed up.

Example/e2e tests: It's all protractor now so those would need to be updated to use the new format. Finally, all of the e2e tests run within the context of the docs app (currently), no changes are necessary to the karma config to make those work. You can see a bunch of how this looks at #6232 ... actually thats a bad example since julie already merged ptor example conversions, so lemmec... 7aef2d5 that's a better example... However once the dgeni migration happens, it will prpbably need to change more.

@IgorMinar

This comment has been minimized.

Show comment Hide comment
@IgorMinar

IgorMinar Mar 19, 2014

Owner

I'm bumping this to 1.3.0 milestone, but I'm not making any promises. We are working on a ton of other things that got more votes from the community, so this one is definitely a low priority item at the moment.

The magnitude of the change needed makes it really hard to process this PR, but there is no way around that, it's just a matter of finding the time to do it.

Owner

IgorMinar commented Mar 19, 2014

I'm bumping this to 1.3.0 milestone, but I'm not making any promises. We are working on a ton of other things that got more votes from the community, so this one is definitely a low priority item at the moment.

The magnitude of the change needed makes it really hard to process this PR, but there is no way around that, it's just a matter of finding the time to do it.

@Onumis

This comment has been minimized.

Show comment Hide comment
@Onumis

Onumis Nov 7, 2014

+1 for this!

Onumis commented Nov 7, 2014

+1 for this!

@tangentfairy

This comment has been minimized.

Show comment Hide comment
@tangentfairy

tangentfairy Nov 19, 2014

I'm having the same issue, would like to see this added

I'm having the same issue, would like to see this added

@gurdotan

This comment has been minimized.

Show comment Hide comment
@gurdotan

gurdotan Dec 8, 2014

Same here, this is really needed.

gurdotan commented Dec 8, 2014

Same here, this is really needed.

@adrianduke

This comment has been minimized.

Show comment Hide comment
@adrianduke

adrianduke Dec 11, 2014

+1

+1

@jdscolam

This comment has been minimized.

Show comment Hide comment
@jdscolam

jdscolam Dec 12, 2014

+1 as well.

+1 as well.

@MasFauzi

This comment has been minimized.

Show comment Hide comment
@MasFauzi

MasFauzi Dec 12, 2014

I need it

I need it

This comment has been minimized.

Show comment Hide comment
@MasFauzi

MasFauzi Dec 12, 2014

Host connection

Host connection

@ddahan

This comment has been minimized.

Show comment Hide comment
@ddahan

ddahan Dec 15, 2014

+1 too..

ddahan commented Dec 15, 2014

+1 too..

@petebacondarwin petebacondarwin modified the milestones: 1.4.x, 1.3.x Dec 16, 2014

@petebacondarwin petebacondarwin assigned shahata and unassigned IgorMinar Dec 16, 2014

@altryne

This comment has been minimized.

Show comment Hide comment
@altryne

altryne Jan 8, 2015

👍
I really think that using routing in your SPA, without the possibility to define that all cookies will have the same path is problematic and even error prone!

altryne commented Jan 8, 2015

👍
I really think that using routing in your SPA, without the possibility to define that all cookies will have the same path is problematic and even error prone!

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Jan 8, 2015

Member

@altryne - does #10530 solve the problem for you?

Member

petebacondarwin commented Jan 8, 2015

@altryne - does #10530 solve the problem for you?

@altryne

This comment has been minimized.

Show comment Hide comment
@altryne

altryne Jan 8, 2015

@petebacondarwin hey, I'm not sure how to try this out, but what I don't see there is a global config, so I can set up my default params like path , expiry and domain once

altryne commented Jan 8, 2015

@petebacondarwin hey, I'm not sure how to try this out, but what I don't see there is a global config, so I can set up my default params like path , expiry and domain once

@petebacondarwin

This comment has been minimized.

Show comment Hide comment
@petebacondarwin

petebacondarwin Jan 8, 2015

Member

@altryne - can you comment on that PR so that @shahata can ensure that he covers your use case?

Member

petebacondarwin commented Jan 8, 2015

@altryne - can you comment on that PR so that @shahata can ensure that he covers your use case?

@altryne

This comment has been minimized.

Show comment Hide comment
@altryne

altryne Jan 10, 2015

@petebacondarwin now looking at it again, this was indeed supported!
An options parameter was added to $cookieStore.put() which supports passing path, domain, expires and secure parameters.
thanx!
hope this will land sometime soon

altryne commented Jan 10, 2015

@petebacondarwin now looking at it again, this was indeed supported!
An options parameter was added to $cookieStore.put() which supports passing path, domain, expires and secure parameters.
thanx!
hope this will land sometime soon

@lgalfaso

This comment has been minimized.

Show comment Hide comment
@lgalfaso

lgalfaso Mar 12, 2015

Member

The new cookies implementation landed, this can be closed

Member

lgalfaso commented Mar 12, 2015

The new cookies implementation landed, this can be closed

@lgalfaso lgalfaso closed this Mar 12, 2015

@mike-spainhower

This comment has been minimized.

Show comment Hide comment
@mike-spainhower

mike-spainhower Mar 17, 2015

👏

👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment