-
Notifications
You must be signed in to change notification settings - Fork 1.4k
fix(file_upload): validate mimetype as configured #1459
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
fix(file_upload): validate mimetype as configured #1459
Conversation
2e4689b
to
f094ebc
Compare
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.
Tests look very clean. Thanks this already great as it is, but I would prefer some slight changes to validation architecture -- separating HTTP logic from validation logic. Important as we'll add more such functionality going forward, good to have the API clean now.
backend/chainlit/server.py
Outdated
file_response = await session.persist_file( | ||
name=file.filename, content=content, mime=file.content_type | ||
) | ||
|
||
return JSONResponse(content=file_response) | ||
|
||
|
||
def validate_file_upload(file: UploadFile): | ||
if config.features.spontaneous_file_upload is None: | ||
return # TODO: if it is not configured what should happen? |
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.
The most elegant solution is to change the default value for config.features.spontaneous_file_upload
to always be populated with SpontaneousFileUploadFeature
then to have enabled
default to False
and move max_files
and max_size_mb
default values from the frontend to the backend config. This would remove the if ... is None
in favour of more explicit code. But I get it if perhaps that's out of scope and left for a later PR.
The second best would be to follow the frontend in this and not allow uploads unless explicitly enabled. Definitely, we should try to avoid having a TODO in a PR. ;)
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.
The current behaviour for the e2e tests is that it is None. So rejecting upload when it is not configured will break the tests and might also break things for users.
I agree that the best would be to not have None as the default, but this indeed seems out of scope.
Where would you put the validation logic? |
This is what I referred to in that comment: #1459 (comment) |
d0f41f7
to
ddbe7ab
Compare
Hi @dokterbob is anything else missing? |
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.
Looks good to me! Thanks @qvalentin!
# Conflicts: # backend/tests/test_server.py
87f1c23
to
37661ec
Compare
#1458