summaryrefslogtreecommitdiffstats
path: root/net/base/cookie_store.h
Commit message (Collapse)AuthorAgeFilesLines
* Reapply r61237: FBTF: Another big ctor/dtor cleanup found by automated tools.erg@google.com2010-10-041-14/+6
| | | | | | | | | | | | | | | Removes changes to code in webkit/ that broke chrome_frame. Will debug that portion later. (Shaves ~2MB off Linux Debug .a files) BUG=none TEST=compiles First Review URL: http://codereview.chromium.org/3563004 Review URL: http://codereview.chromium.org/3621003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61435 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "FBTF: Another big ctor/dtor cleanup found by automated tools."erg@google.com2010-10-011-6/+14
| | | | | | | | | | | This reverts commit 27ea47d65cf8767f350113d5ad9e25170efde811 (r61237). BUG=none TEST=compiles Review URL: http://codereview.chromium.org/3609005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61240 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Another big ctor/dtor cleanup found by automated tools.erg@google.com2010-10-011-14/+6
| | | | | | | | | | | (Shaves ~2MB off Linux Debug .a files) BUG=none TEST=compiles Review URL: http://codereview.chromium.org/3563004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61237 0039d316-1c4b-4281-b951-d872f2087c98
* Move ASCIIToWide and ASCIIToUTF16 to utf_string_conversions.h. I've found itbrettw@chromium.org2010-07-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | weird that UTF8ToWide is in utf_string_conversions, but ASCIIToWide is in string_util.h. This should help some dependencies since string_util changes much more frequently than utf_string_conversions and fewer files will now need string_utils. Since this requires a lot of changes, this keeps a forward-declaration in string_util so I can update the entire project incrementally. This change updates base and net only. I removed some includes of string_util from header files in net. In particular, url_request_context which involved creating a new .cc file to implement a function (already virtual so there's no speed penalty). It turns out a lot of files were getting string_util from this include, so I had to update a bunch of random files to now explicitly include string_util.h TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/3076013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54456 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 38001 and 38002.darin@chromium.org2010-02-031-26/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify CookiePolicy to work asynchronously This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is threadsafe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the setcookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/564045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38028 0039d316-1c4b-4281-b951-d872f2087c98
* Back out trunk r37998.mark@chromium.org2010-02-031-32/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Modify CookiePolicy to work asynchronously This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. I also filed a bug about making it even closer in functionality. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is threadsafe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the setcookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/567015 TBR=darin@chromium.org Review URL: http://codereview.chromium.org/562037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38002 0039d316-1c4b-4281-b951-d872f2087c98
* Modify CookiePolicy to work asynchronouslydarin@chromium.org2010-02-031-26/+32
| | | | | | | | | | | | | | | | | | | | | This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. I also filed a bug about making it even closer in functionality. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is thread-safe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the set-cookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/567015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37998 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this.ananta@chromium.org2010-01-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function TBR=amit Review URL: http://codereview.chromium.org/521072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35778 0039d316-1c4b-4281-b951-d872f2087c98
* Reason:tyoshino@chromium.org2010-01-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux Builder (ChromiumOS) failed. http://chrome-buildbot.corp.google.com:8010/builders/Linux%20Builder%20(ChromiumOS)/builds/2050/steps/compile/logs/stdio Please add changes to external_cookie_handler_unittest.cc no to break compilation and reland? ---- Revert 35769 - Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the SetCookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/517070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35771 0039d316-1c4b-4281-b951-d872f2087c98
* Deleting cookies by setting the expires attribute on them with an empty ↵ananta@chromium.org2010-01-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35769 0039d316-1c4b-4281-b951-d872f2087c98
* Second patch in making destructors of refcounted objects private.jam@chromium.org2009-11-051-2/+4
| | | | | | | | BUG=26749 Review URL: http://codereview.chromium.org/368001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31165 0039d316-1c4b-4281-b951-d872f2087c98
* This CL changes the CookieStore obect to be a refcounted object to get a ↵ananta@chromium.org2009-09-051-2/+3
| | | | | | | | | | | | better handle on its lifetime as there are cases where this object is handed out to URLRequestContext instances which outlive the URLRequestContext object which created it. Partial fix for http://code.google.com/p/chromium/issues/detail?id=15289 Bug=15289 Review URL: http://codereview.chromium.org/197023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25558 0039d316-1c4b-4281-b951-d872f2087c98
* Make CookieStore dtor virtualamit@chromium.org2009-07-281-0/+2
| | | | | | | | | | | CookieMonster is deleted using the CookieStore ptr. Make the dtor virtual so that the correct dtor is called. TBR=darin Review URL: http://codereview.chromium.org/160271 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21838 0039d316-1c4b-4281-b951-d872f2087c98
* Navigation and cookies for Automationamit@chromium.org2009-07-281-0/+64
Give Automation better visibility and control over navigations. Also, make it possible for automation to implement a dummy cookie store to go with dummy request serving over automation. BUG=none TEST=none Review URL: http://codereview.chromium.org/159189 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21836 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-18 12:11:24 +0000