-
Notifications
You must be signed in to change notification settings - Fork 334
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
Blur SSR by default when content warning is set #2430
Blur SSR by default when content warning is set #2430
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With these changes, if a user has already consented or is logged in, they always get a blurred document sent back to the browser. This is the opposite problem than we were running into originally.
Also, didn't you say you wanted to prevent the browser from downloading NSFW material entirely? Because even if we get the blur working correctly, that NSFW content is still getting downloaded by img tags.
The original PR now works if we're trying to go with the blur. It always makes the document returned from the server blurred when appropriate while also not sending a blurred page back to users who are logged in or already consented. |
There blur would have been removed on the client before the html was fully parsed.
I believe your thinking of this LemmyNet/lemmy#4625 . |
I was referring to your comment in the maintainer chat. I may have misunderstood you, but I thought your concern was the browser of a nonconsenting user downloading the image files posted on both the local and federated instances, as opposed to controlling whether a post gets federated with another server. |
I'm not in any chat. |
I am so sorry about that. I got you confused with @MV-GH. |
Yeah that was my concern, whether or not the user had consented. The files are already stored. |
With the cookie approach this should be doable by just adding another guard like auth-guard. But it probably needs a page refresh to update the isoData. The error-guard is currently also stuck, once it sees an error, it will see the same error for the next route too. |
No description provided.