That sounds like a good general API. Watir has had the CookieManager trailing around for a while as a contributed component. I'm not sure how many people use it, but it's a bit weak and is more of an addon than truly integrated into the core API which it should be. I've hacked around that area a bit for some of the gap common domains, and cookie refreshes.
I'd like to get more feedback from users, as this is a fairly common case. I'll ping a few people as well, since the Gap uses various toplevel domains and redirection but some common cookies across domains for a type of SSO. A lot of the cookie work there was visiting custom urls for refreshing/deleting. FB had something similar. This is a good idea to incorporate cookie management more cleanly, and the api looks good. Next steps imho, let's figure out who if anyone is using the CookieManager, and deprecate that. Pull a few use cases from some companies that are doing a lot cookie management, write some tests and implement. Thoughts? Charley Baker Lead Developer, Watir, http://watir.com On Mon, Jan 3, 2011 at 11:58 AM, Jari Bakken <[email protected]> wrote: > On Mon, Jan 3, 2011 at 7:05 PM, Jarmo <[email protected]> wrote: >> In #watir channel we had a short discussion about a possible unified API >> between all current Watir implementations. We came up with an API like this: >> browser.cookies # returns Cookies object which includes Enumerable >> browser.clear # removes all cookies >> browser << new_cookie # adds cookie >> browser.delete new_cookie >> #<< should take a Cookie object as an argument if i understood correctly >> with #delete cookies are deleted only by "name" when talking about >> Watir-WebDriver, but maybe it's/will be different with other implementations >> so #delete should also take a Cookie object as an argument. Or maybe just >> "name". > > You probably mean browser.cookies.clear, browser.cookies << etc. > Something like this: https://gist.github.com/763769. > > I think #add wouldn't need to take a separate Cookie object - a Hash > will probably do fine (the Cookies class can do some validation). The > way it works in WebDriver (which IMO it would make sense to adopt), > cookies look like this: > > { > :name => "foo", > :value => "bar", > :path => "/some/path", > :domain => "some.domain", > :expires => DateTime, > :secure => true/false > } > > When adding a Cookie, only the :name and :value keys are mandatory, > :path defaults to "/", :secure defaults to false, :domain defaults to > the current domain, and :expires will only be set if set by the user > (valid types are Time, DateTime, or Numeric (number of seconds)). > > A constraint in WebDriver is that cookie manipulation only affects the > current domain - if Cookies#add is called with another domain, it will > raise an InvalidCookieDomain error. Likewise, Cookies#clear will only > clear cookies for the current domain. I'm not entirely sure what the > reason for this is (I'm suspecting IE), perhaps Simon can shed some > light. If we want cross-browser compatible, we may need to > (artificially) impose this constraint , even for implementations that > can support cross-domain cookie manipulation. > > Jari > > > > > > > > > > >> Jari liked more the API where "name" is the argument due to the limitations >> of WebDriver, but this would mean that if user has a Cookie object already >> then he/she had to execute #name explicitly. I wouldn't make that as a >> requirement. >> I also noticed that currently Watir doesn't have anything related with >> cookies except CookieManager, which seems not to be best. And nothing for >> FireWatir. That means that the API for cookies is an open subject and free >> to change, i guess. >> What are other's thoughts about the matter? >> Jarmo >> _______________________________________________ >> Wtr-development mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/wtr-development >> > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
