-
Notifications
You must be signed in to change notification settings - Fork 6
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
guard zip export with a permission #35
Comments
we should also add a browserlayer to this package. currently zip_export can be invoked even if the package is not installed on the plonesite. what do you think about this @jone? |
Yes, we should definitively protect the view with a custom permission! I'd not add a browserlayer because:
|
the permission should be also given to Anonymous role by default or you are going to create a problem OOTB; I personally prefer to handle that at the front end server: caching the whole file in the web server is quite easy. some documentation should be provided for both use cases. |
@jone and @hvelarde thanks for your feedback. @jone: did not know about the browserlayer problem - the permission is sufficient then. @hvelarde: i don't understand why we are creating a problem out of the box if we do not allow zip_export for anonymous users. personally i'd break with backward compatibility in favour of robustness. if @jone as a maintainer prefers to stay with the current behaviour i'm fine with that too and will change permission settings in my policy package. and yes, the permission should be documented in the readme |
@frisi maybe I misunderstood the problem; I don't remember how this is implemented, but we're using it to allow anonymous users download full photo galleries and want to keep that without changes. check an example: http://www.brasil2016.gov.br/pt-br/galeria-de-fotos/parque-olimpico-da-barra-dezembro-de-2015 |
Anonymous: DOS-Prevention with proxy config: Configure downloadable content: View / Public: New ZIP permission: So as I see it now, the problem is not the permission, but the lack of documentation for the zip-export setting, combined with the default of I propose to leave the permissions as it is now and extend the documentation for the zipexport settings and maybe also with some of the thoughts about DOS attacks. What do you think? |
+1 |
just installed the addon in an intranet and went through this ticket again. for usage on big websites i think the additional permission is still a good idea. so i'm fine for keeping the default roles for the zip-download permission very open (same as view-permission - to not break usecases like the one of hector) but i'd still vote for a custom permission to not only limit the zip_export action to certain interfaces, but also the ability to show the action only to a subset of authenticated users. |
currently anonymous users can simply download a folder's content as zip by visiting path/to/folder/zip_export
can't this be used for DOS attacks?
possible solution:
add a permission "ftw.zipexport.DownloadZip" "ftw.zipexport: Download ZIP"
that is given to manager and siteadmin by default.
and use this permission to guard the @@zip_export view.
integrators can grant this permission to other roles (even Anonymous) and overwrite the
@@zipexport-enabled
view.The text was updated successfully, but these errors were encountered: