Closed GoogleCodeExporter closed 9 years ago
CEF currently uses an in-memory cookie store. It is necessary to provide a
PersistentCookieStore implementation like Chrome's SQLitePersistentCookieStore
in order to persist cookie data. This implementation would then be passed as
the first argument to the net::CookieMonster constructor in
BrowserRequestContext::Init().
Persistence of localStorage data is currently supported (issue #139). What
other kinds of user data are you seeking to persist?
Patches to support persistence of the various user data types are welcome.
Original comment by magreenb...@gmail.com
on 23 Feb 2011 at 5:50
i'll take a stab at this sometime this week
Original comment by anthony....@gmail.com
on 28 Feb 2011 at 9:49
here's a preliminary patch that takes SQLitePersistentCookieStore and does the
following:
- Class is renamed to BrowserPersistentCookieStore
- CefThread used in place of BrowserThread
- Instrumentation code removed.
Please consider this a prelimary patch as I'd like to get feedback about the
following things:
- When instantiating the CookieMonster object (in
BrowserReqeustContext::Init()), we should read a settings flag that determines
if the user wants to use a persistent cookie store, or use a purely in memory
cookie store (current behavior).
- Cookie db file should be a file name appended to the cache_path.
Original comment by anthony....@gmail.com
on 1 Mar 2011 at 7:49
Attachments:
The patch looks good so far.
1. If the cache_path is empty don't create a BrowserPersistentCookieStore (pass
NULL to the CookieMonster constructor).
2. The cookie db file name should be appended to the cache_path. If possible,
let's use the same file name that Chromium uses.
Original comment by magreenb...@gmail.com
on 1 Mar 2011 at 2:27
Sounds good, expect an updated patch that addresses these two issues soon.
More generally, it's somewhat of a shame that we're basically copying this code
from src/chrome and pasting it into src/cef. Is there a long term plan to move
useful classes like this into a shared location?
Original comment by anthony....@gmail.com
on 1 Mar 2011 at 5:50
I agree that copying code is a shame. Attempts to move Chromium code to common
locations (which often requires some abstraction of the code) has been met with
indifference or hostility from the Chromium community in the past, so I've
pretty much stopped trying.
Original comment by magreenb...@gmail.com
on 1 Mar 2011 at 6:11
stupid question but what's the preferred way to use the FilePath api to append
a filename to a directory path?
Original comment by anthony....@gmail.com
on 2 Mar 2011 at 12:06
The Append or AppendASCII methods of FilePath are likely your best options. Use
the former if you're appending another FilePath and the latter if you're
appending a constant (ASCII) string.
Original comment by magreenb...@gmail.com
on 2 Mar 2011 at 12:18
if i pass cache_path.AppendASCII("Cookies") as the parameter to the
BrowserPersistentCookieStore constructor, it becomes a bad pointer some time
before the Backend class tries to open the file. please advise.
Original comment by anthony....@gmail.com
on 2 Mar 2011 at 12:47
Try assigning to a variable first:
FilePath path = cache_path.AppendASCII("Cookies");
Original comment by magreenb...@gmail.com
on 2 Mar 2011 at 12:56
sorry, i'm a bit rusty on c++. updated patch attached.
Original comment by anthony....@gmail.com
on 2 Mar 2011 at 1:34
Attachments:
Thanks, committed as revision 196 with the following changes:
1. Use scoped_refptr<> instead of a raw BrowserPersistentCookieStore pointer in
BrowserRequestContext::Init.
2. Create the cache_path directory in BrowserRequestContext::Init if it doesn't
already exist.
Original comment by magreenb...@gmail.com
on 2 Mar 2011 at 2:25
Original comment by magreenb...@gmail.com
on 2 Mar 2011 at 2:25
ah, nice. thanks.
Original comment by anthony....@gmail.com
on 2 Mar 2011 at 2:40
Thanks! This is working great.
Anthony, if you would like a license to our software, even if it's just to see
your work in action, drop me a line: matt at jriver dot com.
A similar offer for magreenblatt:
http://magpcss.org/ceforum/viewtopic.php?f=6&t=228
Original comment by jriver.d...@gmail.com
on 2 Mar 2011 at 11:38
Original issue reported on code.google.com by
jriver.d...@gmail.com
on 23 Feb 2011 at 4:53