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

Documentation for HTTPS Request with cookie? #18

Open
rustrust opened this issue Nov 1, 2022 · 5 comments
Open

Documentation for HTTPS Request with cookie? #18

rustrust opened this issue Nov 1, 2022 · 5 comments

Comments

@rustrust
Copy link

rustrust commented Nov 1, 2022

Would it be possible to get some documentation on how to connect ehttp to perform https requests submitted with cookies, and how those cookies can be set via the response? Thanks!

@emilk
Copy link
Owner

emilk commented Feb 28, 2023

I think adding docs for that would be great. Would you like to help out?

ehttp is a very thin wrapper around ureq and web_sys::Request, so it should be pretty easy to figure out!

@rustrust
Copy link
Author

rustrust commented Oct 5, 2023

Would it be possible to have cookies as a first-class feature in ehttp?

@Vrixyz
Copy link
Contributor

Vrixyz commented Nov 16, 2023

For reference: cookies can be accessed within response.headers.

I'm not sure what you mean by "first class" ? I'm guessing either:

  • Some way to more easily retrieving cookie values from a single request (from response.headers), I'm not sure how much simpler it would be compared to bringing another dependency to parse the cookie (I guess https://docs.rs/cookie/latest/cookie/ ?)
  • Automatic retrieving of cookies, storing and sending them again, I'm not the maintainer, but I think it's quite complex to add, and likely to fit better in another library wrapping around ehttp:
    • Where do you store the cookie ? in memory ? in a file ?
    • secure cookie (http only) are a thing, how should they be handled.
    • expiry handling
    • Probably other things I did not think about.

@rustrust
Copy link
Author

rustrust commented Dec 7, 2023

I see set-cookie in the response headers when visiting common websites.

Yes I am asking about proper overall handling of the cookie including storage for both native and wasm egui applications, including storage. If I would need to make my own decisions about cookie storage, some guidance would be useful...

@jheidecker
Copy link

I see set-cookie in the response headers when visiting common websites.

Yes I am asking about proper overall handling of the cookie including storage for both native and wasm egui applications, including storage. If I would need to make my own decisions about cookie storage, some guidance would be useful...

I am currently building an app that needs to talk to a bunch of different REST APIs at different domains.

A WASM app using ehttp is using (the same as all rust http libraries that compile to WASM i know of:) web-sys underneath, which provides binding to the browsers API. The browsers API, in contrast to native capabilities, enforces a lot of things that seem strange at first, but make sense if you think about security in the browser context.

CORS and credential (e.g. cookie) handling will cause headaches if you are trying to cross-compile an app native/WASM that needs credentialed http requests to other web servers or REST APIs. Forget about CORS for a moment, as this assumes a lot of control and setup of the serving APIs.

Most importantly, you can't read and send the cookie (or any credential afaik) like you would in a native app. There is not library you can wrap cookie handling in. The browser API forbids any code (including WASM) from sending a Cookie directly.

You need to have the server send a Set-Cookie header, which will store it in the browser, and then tell web-sys (ultimately Fetch) to use that cookie in other requests. see: https://developer.mozilla.org/en-US/docs/Web/API/Request/credentials

I've made a PR to add the credential property to ehttp requests and tested it to work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants