This Community is intended for posts about the Lemmy.world server by the admins.
For support with issues at Lemmy.world, go to the Lemmy.world Support community.
Any support requests are best sent to info@lemmy.world e-mail.
If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.
If you can, please use / switch to Ko-Fi, it has the lowest fees for us
That's not a good idea, because that would allow any website a logged in user visits to impersonate them (e.g. link to a malicious site posted somewhere, users click on it, JS on the site starts posting the same link in their name, more users click on it, ...).
But react native doesn't restrict cross-domain access like browsers do, so it shouldn't be an issue in your case: https://reactnative.dev/docs/network#using-other-networking-libraries
I planned on exporting a web version as well and I was testing there first hence the issue.
How would this allow any website to impersonate you though? The login is made via a jwt which would not be accessible if you go in another website. If I login on mysuperlemmyclient.com and then visit maliciouswebsite.com, how can maliciouswebsite access the jwt that is stored likely in a cookie of mysuperlemmyclient.com?
The user's browser will send it along with the request depending on the samesite cookie settings.
The best solution would be if lemmy used federated identity (e.g. OIDC), not sure why they aren't doing that.
Hey, looks like someone has the same idea - unless this is also you. :)
The headers are set inside the Lemmy binary/docker image. So unless lemmy.world would use its own build, this has to be fixed inside the LemmyNet source code. This would probably make Lemmy vulnerable to cross-site scripting, so the security aspects should probably be discussed in on the Github project.
I just did some more research into this:
When a client tries to log in, the server sends a response back with a JWT token inside the body. The client then stores this token inside an isomorphic cookie. This cookie is then used to identify the user by adding it to all requests after that.
I haven't really checked post requests, but if it is the same So let's say you visit website X, that has nothing to do with Lemmy, they could do a Fetch request in the background to lemmy.world to post spam on your behalf. Even a CSRF token could no longer protect you, as the website could just do a fetch request first to get a CSRF token.
I hope I'm wrong in some way, but to me this feels like a huge security risk.
Wouldn't the real process here to just make your own instance with a different front end? Either that or make it an electron app etc.
There's a lot of security issues by disabling CORS.
