New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CookieStore support? #263

Open
storezhang opened this Issue Oct 31, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@storezhang
Copy link

storezhang commented Oct 31, 2017

When can you support cookie functionality?

@PerfectedTech

This comment has been minimized.

Copy link

PerfectedTech commented Dec 24, 2017

+1

@markGilchrist

This comment has been minimized.

Copy link
Collaborator

markGilchrist commented Jul 22, 2018

@storezhang
if you can elaborate on what functionality you are looking for I will make a pr and implement it

@C06A

This comment has been minimized.

Copy link

C06A commented Jul 25, 2018

Cookies transported between client and server as header.
The CookieStore is not part of the communication protocol and should be implemented by client you are building on top of Fuel. It is not that difficult.

The only functionality in support Cookies I see is parsing and formatting Cookies header in Response and Request respectively.

@markGilchrist

This comment has been minimized.

Copy link
Collaborator

markGilchrist commented Jul 25, 2018

@C06A

Thanks for your answer, does this pr -> #393 go someway to starting this functionality?

Do you have a working example I can look at so I get a precise list of functionality to build this?

@PerfectedTech

This comment has been minimized.

Copy link

PerfectedTech commented Jul 25, 2018

I had in mind something like what RestSharp does with their cookie management. There was another library I used in the past that had a like feature, but the name of it escapes me right now.

https://github.com/restsharp/RestSharp/wiki/Cookies

Any request the HTTP client makes, it will persist the cookies, much like a browser might do.

@SleeplessByte

This comment has been minimized.

Copy link
Collaborator

SleeplessByte commented Jul 25, 2018

@markGilchrist @kittinunf I think the request here is not specifically cookie store, but session management (which for a client is basically cookie persistence). On android, the cookie store here: https://developer.android.com/reference/java/net/CookieStore is automagically called! This is what calls it: https://developer.android.com/reference/java/net/CookieManager.

Additionally, the HttpClient used right now is explicitly set to NOT use caching, whereas Android has a great File cache that works similarly. Needs a separate ticket, but similar implementation.

It probably should NOT be Fuel's responsibility to handle sessions, just allow for it (have the interface).

@markGilchrist

This comment has been minimized.

Copy link
Collaborator

markGilchrist commented Jul 26, 2018

@SleeplessByte do we need to define our own interface or should we recommend users user the ones provided by android? do we need to implement any code or is this outside our remit for this project?

@C06A

This comment has been minimized.

Copy link

C06A commented Jul 27, 2018

Fuel is not implemented specifically for Android, so I would recommend to avoid platform-specific implementation.
As I mentioned before I think this is a functionality of the higher order.
Especially if we talking about session management. Client is not always browser and server may require different ways to communicate session info. All these depends on specific task.

For example REST API provided by Spring security relies on completely different set of headers and not cookies at all to manage sessions.

@SleeplessByte

This comment has been minimized.

Copy link
Collaborator

SleeplessByte commented Jul 27, 2018

Fuel is not implemented specifically for Android, so I would recommend to avoid platform-specific implementation.

Agreed with this! @markGilchrist so your own interface would probably work well; or not do it at all but have access points so people can do it themselves.

The easiest solution is probably something along the lines of:

  1. extract the current http client creation into a factory method that people can intercept
  2. make it easy to set the http client / read it
  3. add examples in the docs how to make this work with java 7/8 and android

For example, the android default http client can handle sessions and cookies by itself. Regardless of using Fuel! The fuel-android library can then have a default setup for example that sets it up for Android.

What @C06A is right, which is why I said: they probably want sessions, not just cookies.

@clarfon

This comment has been minimized.

Copy link

clarfon commented Aug 16, 2018

IMHO-- while some form of session support would be nice, I think that cookie support will be desired regardless of whether sessions exist or not. I'm working on migrating from Jsoup to Fuel for network requests and would love a simple way of parsing the cookie headers through fuel, as they have a few nontrivial aspects such as:

  1. The Set-Cookie syntax needs to be parsed for the Expires and Max-Age fields in order to determine whether data is expired, and upon making new requests this needs to be checked again.
  2. Which domains/paths the cookies apply to need to be checked as well.
  3. Cookies may have to be URL-decoded/encoded for them to be valid.

Ideally, an API for this would be, in order of usefulness:

  1. Any API on Response to get a List<Cookie> back from the Set-Cookie headers, where Cookie can just be a data class for now with the relevant information.
  2. An API on Request to add Pair<String, String> (or more likely Pair<String, Any?> cookies to the request.
  3. A CookieJar class which can add Cookies and functionally acts like List<Cookie> while also tracking expiration dates and such.
  4. Attaching a CookieJar to a request, or getting the relevant cookies that would be attached for a particular URL.
  5. Serialisation and deserialisation of CookieJars.

The CookieJar class would functionally act like a session, although in the future another Session wrapper could be made which contains additional guarantees. (not sure what those would be)

One thing that's relatively nice about Jsoup is that you can, at minimum, attach a Map<String, String> of cookies to a request and get one out. While I feel that this is too restricting and List<Cookie> is a bit better, it's a start.

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