🎉 Better Boilerplate by Not Quite Unicorns - Our take on what a good Bubble app looks like

[boston85719]

@akamarski

Better validate actions on the backend rather remember to validate on every frontend call to this same workflow

Okay thank you. I was and am genuinely curious about whether or not there is a security component to it as I want to learn more about an area I am less familiar with due to my lack of ability to test against users changing values client side to ‘hack’ the app. So, @akamarski to summarize, there is not security benefit to use one over the other, it is simply just an easier way to do it so as to not forget.

@georgecollier

It can be set by triggering a custom event from the sidebar reuseable element to collapse/expand the sidebar.

I understand that. I’ve mentioned to @randomanon that point.

@georgecollier

The property is just the source of truth for its current state, used in conditional formatting on its parent page.

Okay, I didn’t even recognize you are ALSO incorporating a property into the mix as well. So a group, a custom event and property all just to replace a custom state, okay, to each his own.

@georgecollier

my clients value my time more than the negligible WU costs for things like this

It improves maintainability, which means I need less hours to get things done, which means my clients spend less with us and still get a better job done.

@georgecollier

And it means that we can charge an effective rate (we don’t bill hourly) of well over $200 an hour

Okay, so there is not a security benefit? Remember, I ask because I want to learn, not to question your method. Security is not something I’ve focused on and I default to those who have niched themselves into areas I lack experience in for guidance and learning. I thought this post and app shell were for that.

So to sum up on that conditional evaluation, it is just that it allows you to work faster? I suppose that if clients are charged per hour that tracks as a benefit to the client, but if they pay a subscription fee and only care about things getting done and not how long they take you, than the client may benefit from consideration of their WU costs in how the app is put together.

But, yes, I see the point, it is easier and makes it more maintainable to just call to the backend workflow especially if it is used in more than one place and doesn’t already have an action in the series that already confirms the permission of the user via a reusable element with custom events to return a yes/no value of ‘isUnauthorized’. Again, I ask because I am genuinely curious about security things I do not know about. Seeing so much redundancy in the security measures makes me curious if it is all necessary or not since I do not have an ability to change the user role from client device to test these things myself, so I have to ask somebody who is doing it about the rationale for it and the implications of doing it or not.

@georgecollier if a malicious user can change their role via client side, can they also change the return value of ‘isUnauthorized’ or is that not possible since the value is not downloaded on page load like ‘current user’ data is (where ‘role’ would be defined and changeable) and being returned in workflow action doesn’t give malicious user an opportunity to change it while the actions are running?

Thanks for sharing George, gives me a lot to have to dive deeper into security about.