Able to access circles I'm not a member of by visiting the URL directly

How is it now?

I logged out, cleared my cache and reloaded https://test-paris.happy-dev.fr/circle/@http~@~_~_localhost~@8000~_circles~_2~_/circle-information and was presented with the circle's information despite not being a member (tested with circle-css branch also)

How should it be?

I should be presented with a 404 or 403 page

Steps to reproduce

(How one can reproduce the issue - this is very important)

1. log out & clear cache
2. visit https://test-paris.happy-dev.fr/circle/@http~@~_~_localhost~@8000~_circles~_2~_/circle-information

Possible fixes

• For fixing the access the backend needs to return a 404 or 403 for user.is_anonymous
• The front-end might then redirect to a 404 or 403 page when it gets this response. Or possibly it is sib-display which should render 404 or 403 content?

added 1 deleted label

changed the description

That's because anonymous have read permissions on a Circle: https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-circle/blob/master/djangoldp_circle/models.py#L30

About 404, for now, on client-side we don't handle them. Beside that, we have sib-ac-checker that can check webacls. We are currently using it on Circle information page but we only show a blank page on no permissions to.

I guess, in case of a public circle, the ideal scenario would be to that only a few fields public, and the rest inaccessible if you are anonymous.

@jbpasquier, @balessan, @sylvain, @clement, @matthieu : The only way to have that in a Solid world is to have nested containers?

By Alexandre on 2019-11-19T17:55:04 (imported from GitLab project)

Or a second resource. That's a known limitation of WebACLs, but Solid seems to be happy with that. See https://git.happy-dev.fr/startinblox/solid-spec/issues/14

changed milestone to %10

mentioned in issue #420 (closed)

mentioned in issue #198 (closed)

@alexandre is this one similar to https://git.happy-dev.fr/startinblox/applications/sib-app/issues/257 ?

@rachel Ah ah, tough one. I'd say no eventually, but they do talk about the same thing, yes.

This one is about the WebACL part of it, precisely which information of a public circle should be visible to a user that is not a member of that circle. I disagree with Calum that a 404 should be shown to the user. Circles are meant to be public by default. Not being a member of a circle doesn't mean you are blocked from accessing it. It mostly means that you do you receive notifications from that circle, and can't be @mentionned in it. We might want to hide a few information from those non-members on the information page, but I'm not sure which ones.

#257 (closed) is about the Prosody's side of this matter. But thinking about it, maybe #257 (closed) makes no sense. I think I had clearer ideas when I wrote it about what it meant for a MUC to be private in XMPP. Right now, it is a bit foggy and I'm not sure what I wrote makes sense any more. If a Circle is public, I don't see why its associated MUC would be private... Matthew could probably shed some light on the matter to make it clear again.

By Alexandre on 2020-03-14T07:30:30 (imported from GitLab project)

changed milestone to %Private circles (not part of MVP)

This is fixed now except the security issue that needs to be followed in https://git.startinblox.com/infra/security/issues/24

closed