cloudtrends / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
1 stars 1 forks source link

Unable to persist cookies / user data #193

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Visit https://www.netflix.com/Login in cefclient.exe
2. Check 'Remember me on this computer' and login
3. Restart cefclient.exe
4. Note that Netflix does NOT remember the user between runs

What is the expected output? What do you see instead?
Persistence of user data

What version of the product are you using? On what operating system?
CEF 181, any OS

Please provide any additional information below.

In our own application, we're using a persistent path for:
CefSettings.cache_path

What else is required to allow user data and cookies to persist?  This is a 
critical issue in our attempt to integrate CEF.

Thanks for any help.

Original issue reported on code.google.com by jriver.d...@gmail.com on 23 Feb 2011 at 4:53

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
i'll take a stab at this sometime this week

Original comment by anthony....@gmail.com on 28 Feb 2011 at 9:49

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by magreenb...@gmail.com on 2 Mar 2011 at 2:25

GoogleCodeExporter commented 9 years ago
ah, nice. thanks.

Original comment by anthony....@gmail.com on 2 Mar 2011 at 2:40

GoogleCodeExporter commented 9 years ago
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