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

Inconsistency with special-access links #937

Open
Janfred opened this issue Jan 13, 2025 · 4 comments
Open

Inconsistency with special-access links #937

Janfred opened this issue Jan 13, 2025 · 4 comments

Comments

@Janfred
Copy link

Janfred commented Jan 13, 2025

The special-access links have an inconsistency:

When opening the special-access link without being logged in (I haven't tried it with a login), some files cannot be viewed/downloaded from the request overview page.
Censored documents are only shown in the censored variant, although the censored parts of the messages are shown.
In cases where there exists an uncensored and a censored variant, only the censored variant is displayed in the document overview list.

When downloading the complete request history as a ZIP, all documents are included in the uncensored variant.

I believe that the special-access link should show all documents in the uncensored variant and allow downloads of single, uncensored documents, as it is explicitly intended for giving more access than what is publicly available.

@Janfred Janfred changed the title Inconsistency with speical-access links Inconsistency with special-access links Jan 13, 2025
@stefanw
Copy link
Member

stefanw commented Jan 13, 2025

I guess we need to clarify the purpose of documents. The documents generated from PDF attachments are for public distribution and consequently need to be redacted if the underlying PDF attachment required redactions. PDF attachments retain a redacted and an unredacted variant, but if a PDF attachment is converted to a document (meaning marked as a result of an FOI request) then only the redacted variant will be used. This has nothing to do with special-access links. Even regularly authenticated users cannot see unredacted versions of documents, but only unredacted attachments.

@stefanw stefanw closed this as completed Jan 13, 2025
@Janfred
Copy link
Author

Janfred commented Jan 13, 2025

I don't understand the comment.

My use case: I want to give special access to either a lawyer or the LfDI. And they should be able to see everything unredacted.
I used the link sent automatically when requesting a "mediation" from LfDI.

If they open the link, they can see the unredacted text content of mails, but not the unredacted attachments, neither if the attachments have not been published or if only a redacted version of the attachment has been published.
If they download the whole request as ZIP (on FragDenStaat in the right box "Download als ZIP"), the ZIP contains the unredacted attachments.

@Janfred
Copy link
Author

Janfred commented Jan 13, 2025

If there is no unredacted variant of a document, the special access link shows the unredacted document, but when clicking on it it requires a login.
If there is a redacted version, the overview page only shows the redacted version, where the "owner" view shows the public variant and the non-public variant.

The way I assumed the special-access links work is that they show (almost) anything the owner sees, but without the possibility to change anything. (such as sending messages, redact documents, set status, ...)

@stefanw
Copy link
Member

stefanw commented Jan 13, 2025

Thanks for explaining your use case. We make a distinction between 'documents' (e.g. looks like this) and attachments on messages (which can be PDFs). PDF attachments can be promoted to documents but only the redacted version if there is a need for redaction. But you are talking about attachments as I understand it now.

Special-access links should work for attachments, however currently the attachments need to be 'approved' which implicitly means the special-access links can't access redacted attachments. The code is quite explicit about it:

https://github.com/okfde/froide/blob/main/froide/foirequest/auth.py#L285-L293

Not sure why, we will look into it.

@stefanw stefanw reopened this Jan 13, 2025
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

2 participants