Skip to content
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

server side api has Cookie, please add to client side api #20

Open
DartBot opened this issue Jun 5, 2015 · 10 comments
Open

server side api has Cookie, please add to client side api #20

DartBot opened this issue Jun 5, 2015 · 10 comments
Labels
type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/5606587?v=3" align="left" width="96" height="96"hspace="10"> Issue by trinarytree
Originally opened as dart-lang/sdk#19005


https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-io.Cookie
seems to only be available to the server.

that forces other libraries, e.g.
https://docs.angulardart.org/#angular-core.Cookies to implement their own;
or (gasp) the app level code must use the document.cookie api directly.

the angular one isn't nearly as comprehensive as the dart one, e.g.
it doesn't fully support cookie path or expiration dates
(it has really limited support for cookie path).
but really, angular shouldn't have to write such a library,
it should be in dart. you guys already wrote 90% of the code,
you should just share some of it with the client side.
i don't want to have to implement my own crazy DateTime to cookie-date converters.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/17034?v=3" align="left" width="48" height="48"hspace="10"> Comment by kevmoo


We're looking at unifying some http code across client and server. This would be a great candidate.


cc @nex3.
cc @sgjesse.
cc @mkustermann.
Added Type-Enhancement, Area-Pkg, Pkg-Http_parser, Triaged labels.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/17034?v=3" align="left" width="48" height="48"hspace="10"> Comment by kevmoo


See also https://code.google.com/p/dart/issues/detail?id=18845

@DartBot DartBot added the type-enhancement A request for a change that isn't a bug label Jun 5, 2015
@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/1343914?v=3" align="left" width="48" height="48"hspace="10"> Comment by sgjesse


We should consolidate the HTTP utility functions we have. What is already in dart:io should somehow be available in a package for browser use.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3


Removed Pkg-Http_parser label.
Added Pkg-Http label.

@eturk1
Copy link

eturk1 commented Aug 8, 2018

Looks like this issue #20 is still open?
What's the best way to manage cookies in http package?
When we set persistentConnection = true maybe we want cookies managed so the server knows it's the same user on each call?

I ended up using dart:io & getting/setting cookies on every request/response.

@greg-fischer
Copy link

We need this for Flutter Web. I originally built an app on Android where I can store tokens or credentials using FlutterKeychain so that data is stored more securely. But you can't use that on Flutter Web, which led me here (and here).

The OWASP advice is:

Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

[https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage]

Without persistent cookie handlers on repeating API requests how do you store your session identifiers safely in browser? I can see the server response sending the Set-Cookies headers but dart seems to ignore them upon subsequent requests. If developers need to handle the cookies in-browser then we're bypassing the security of the browser. (that's why we use httpOnly cookies, where we can't touch them) However, unless I'm mistaken, doesn't that only leave us with methods that Javascript/Dart(FlutterWeb) can access, which is against OWASP advice.

Please add cookie handling so Flutter Web can use sessions and the built in browser security.

I'll continue reading and investigating on the Flutter side, though, maybe I'm missing something on the http.get request.

Also, about the mention of persistentConnection = true. Am I correct in that this has nothing to do with cookies and server sessions? I'm assuming it refers to the client opening a connection with the server to make multiple requests (POST, GET, etc), after which you manually close the connection.

@jamotaylor
Copy link

jamotaylor commented Oct 9, 2020

@greg-fischer I am also trying to implement security the "right" way using httpOnly cookies stored in the browser. When my HTTP response has 'set-cookie' in the header, the cookie is being ignored by Chrome.

In Flutter Web, the dart http package uses XML Http Requests (XHR) , therefore, the XHR should have the 'withCredentials property set, as per this mozilla doc:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);

It is my understanding the XHR method used to POST the credentials must also have 'withCredentials' set in order for httpOnly cookies to be set in the browser with the response.

But, it seems that the BrowserClient class used in the http package, has the withCredentials property automatically set to false 😞

It should be possible to set withCredentials = true for all the BaseClient request methods, such as post and get. Could this be changed to allow credentials to be sent? Or is this already possible using the http package?

@jamotaylor
Copy link

I have put in pull request #485 to change the default setting in the browser client

@jlubeck
Copy link

jlubeck commented Jan 11, 2021

Is there a workaround for this until the PR gets merged?

@bobjackman
Copy link

bobjackman commented Jul 2, 2024

Friendly bump on this, please? This is still an issue as referenced here (among others) Do we have a workaround? Anything at all?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants