Front-end stream form error when logged out

Front-end stream form error when logged out

twopiers -
1 year ago

Hi everyone, hoping you can help me solve an issue. Clearly I did something wrong here.

I created a stream, defined the fields, etc. All good. One of the fields is a file field type. I then created a front-end form following Ryan’s video. Code looks something like this ("abstractions" is my module name and stream name):

If I’m logged into the Admin and view the front-end form, looks and works great. If I’m logged out of the Admin, I get an error that seems to be coming from the file field type input.twig file (line 14: {{ field_type.value_table|raw }}). A little further down the stack trace it references TableAuthorizer class. Did I miss something regarding permissions?

ryanthompson -
1 year ago

Ok so in \Anomaly\Streams\Platform\Ui\Table\TableAuthorizer it looks like the permission is getting set by default because.. well that's default behavior. Forms behave similarly but because this is a core table (Files module / files stream) it's actually finding a permission and testing it.

I feel like the permissions should only be set by default if in the control panel - otherwise it's up to you to explicitly define them.

ryanthompson -
1 year ago

twopiers -
1 year ago

It's a front-end form that should be publicly available, by default in my humble opinion, but maybe (probably) I'm not understanding your meaning. I build a stream that I want the public to populate via a front-end form without registering as a user. I think that's pretty common, at least in my world. This is basically a "contact us" form with some additional requirements (the file being one of them).

That said, it's your software and I will happily play by your rules. I don't mind explicitly setting permissions, I just have no idea how to do that.

stevenweijdt -
1 year ago

Two things to keep in mind. You need to protect the user (especially the rookies) for any defaults that are dangerous. At the same time.. you should make the number one use case a default.

Permissions in the backend are probably more obvious. You have so many settings a lot of admins are not allowed to touch.. so every serious super admin would set that up correctly with a bit more effort and focus. Also a lot of cases there's just one admin.

On the frontend however, two use cases.

certain type of user can upload files

a guest (so everybody) can upload files

I would go for option 2. But put a big warning and info text in the admin area about permissions. So people know they should be looking at the docs and permissions, in case their use case needs protection.

ryanthompson -
1 year ago

The thing is this is strictly default behavior. @twopiers you can set permissions in protected $options = ['permission' => $permissionString];

Permissions were originally intended for UI builders (and works wonderfully) because the UI builders are providing the response. In the case of including the form in your view it's no longer the response but instead content. So your controller / page or whatever should be responsible for authorizing IMO. I am going to modify the defaults @twopiers so your code should work as expected on the front end.

@stevenweijdt good point on protecting users though.. I have some modifications to a string cleaning function / comments module & forum I think that will make this more responsible on my end in protecting more by default.

ryanthompson -
1 year ago

twopiers -
1 year ago

Just updated, works perfectly. Thanks Ryan! Based on your response, should I be doing this in a different way? Given these parameters, I'm genuinely interested to know how you would approach this? What is best practice?