Wondering what is the general rule for security in each server action (e.g. just security provider, or both SP + SR)?

Server Side Components General
#1

Hey all,

As the title suggests - i’m still building out the app - but will need to soon start to make sure I have everything secured as best as possible.

In any action that the recruiter would require to be logged in, I always have the ‘Security Provider’ and I use that to then get user info. But I see posts every so often on the forum of people always also using the security restrict on workflows?

I use an action file for my node pages that has both security provider and restrict - but wondering if it is best practise to also put the security restrict on each workflow that requires the user to be logged in to use?

#2

Are you talking about the workflows that are built in App Connect and run on the client side?

#3

SC Workflows that are connected on the AC side

#4

Ok
Personally, I would be putting a security restrict on pretty much every server connect file.

I mean I guess you just ask yourself, would you want someone to be able to access the output of the server connect file (whatever it is) without being logged in?

Make all APIs restricted by default
#5

Thanks Philip and they can access this even with the security provider? I thought that was restrictive too

#6

No I don’t think so, without the restrict they could still just access the server connect file by typing in the url.

Once the restrict is put in it though they should get access denied.

I’m sure someone will correct me if I’m wrong, but it’s easy to test even on a local Dev environment

1 Like
#7

OK, that makes sense - thank you. This will take me a while to go back through each SC :sweat_smile:

#8

Yep. I still need to go back and add mine. I’m half holding out to get Argon2 hashing for Node. We’ll see if can hold out that long

1 Like
#9

Think of it as similar to Database Connection and Database Query. The connection part is needed before you can do the query but on its own it doesn’t really do anything.

Security Provider is needed to do anything related to security. Security Restrict is where you actually make it all safe.

I would use Security Provider on its own, for example, to get the ID of the logged in person even if I didn’t want to actually restrict anything. It might be to have ‘Hi Jon’ on the page. The page is public, the data is public, I just want to know it’s Jon who’s logged in.

But, if that page was going to show any data which should only be available to a logged in person then I would add the Security Restrict and set the access level.

I hope that helps.

#10

It does, thanks both.

Follow up question - I have completely public pages that show dynamic data from the db.

Right now, as the anonymous visitor would not have a log in - I just simply have the db connection and the query - no security provider or restrict - would you say that’s fine?

2 Likes
#11

Yep, absolutely fine. If someone browsed to the server connect action file directly they would just see the data output in JSON format exactly the same as if they browsed to the page. The homepage of a shopping site wouldn’t have any restrictions on it so it can display all the products, for example.

2 Likes
#12

perfect, thank you again.

1 Like
#13

Hi there @mgaussie!
Thanks for asking all these great questions!
To me, security provider and security restrict just always always follow each other in every single server action a logged in user will access.

You also need to make sure you have deleted any test server actions where that is not the case before uploading to your remote test or production server for security.

#14

Thank you Antony, sometimes I feel like I’m a bit of a pest - but I do hope those new to Wappler can take some knowledge from these and the answers from the community.

1 Like
#15

Absolutely. These threads weren’t around when I first started trying Wappler a couple of years ago and they would have helped me hugely so it’s good to be able to help build up the information for others.

1 Like
#16

Hey @mgaussie, that is exactly how I felt at the end of last year… I admire your persistance in getting to the bottom of things in a thorough way, and as @sitestreet says, it all helps to build more information for everyone!

2 Likes