Limit access?

[jamesez]

Probably obvious but I'm fairly new to Laravel - how can I limit who can get to Sketchpad? Or: how do I define middleware around Sketchpad?

The root question here is: I write in-house apps, and we have an internal support team. I'd like to make available some tools to that support team that my users don't have access to, but I don't want to spend a ton (any) time writing all the UI for these things. Things like "go get this LDAP attribute to see if it's broken" for solving issues. Etc.

[davestewart]

Hey Jim,

Great that you see a use for Sketchpad, and this is the kind of thing I see it being used for.

There is currently rudimentary support limiting access using a permissions file, and a call from your AppServiceProvider:

• http://sketchpad.davestewart.io/sketchpad/run/help/docs/setup/permissions

I haven't got round to implementing proper middleware integration as I think there are some differences from 5.0 to 5.4. Not sure how I'll implement it in Sketchpad either, probably as a editable setting.

At some point (likely in response to user requests) I will prioritise this; I currently have an open issue:

• https://github.com/davestewart/laravel-sketchpad/issues/42

Feel free to bounce things off me in the meantime!

[achiduku]

Is this the correct place to register another user request for middleware authentication?

[davestewart]

@type-of-null it may as well be :)

I presume you're looking for authentication for access to the initial Sketchpad load, rather than individual controllers (which you could just use controller middleware on) right?

I've been thinking about the right way to do this. Two ideas so far:

1. Have an editable field in Settings, which could be protected using admin.json
2. Add a property to SketchpadServiceProvider which should then be extended by the user with an array of middleware, then you point to this service provider in config/app.php.

Do you have any thoughts or better suggestions?

[davestewart]

@jamesez @type-of-null

Just looking at this now, and by I'm thinking by doing this in the settings page, we could potentially render the site inaccessible by entering invalid middleware keys / class.

I could add in some checks on the back end to filter out invalid classes / keys, but I'm thinking that's more code, complication and a potential security hole, which could be better solved by doing this using an custom ServiceProvider class, or potentially a config file (though I don't want to use config files, as I'm already using the storage folder to store settings).

I'll try the SP route now.

[davestewart]

OK chaps, support for middleware is now implemented in cf5d688d3bcb237f95ea0301da2e04496a4e89a7 by extending the service provider and populating the middleware property.

See: http://sketchpad.davestewart.io/sketchpad/run/help/docs/setup/middleware

Let me know if this works OK for you.

[davestewart]

I've decided to reopen this, as I think I moved too quickly to use a service provider.

On reflection, it seems a bit odd to use both a service provider and admin settings file to specify admin / middleware.

It might be best to use a dedicated Admin class, that manages / loads values from both:

• Config:
  • config/sketchpad.php
  • per app
  • version-controlled
• Settings
  • storage/sketchpad/admin.json
  • per user
  • not version-controlled

Both sources would extend the existing admin.json structure, containing:

{
    "setup": true,
    "settings": true,
    "middleware": [
        "auth"
    ]
}

In theory, both config and settings could be loaded, with the (user) settings overriding the (app) config.

This feels more natural than setting up a service provider.

[jamesez]

What I'd like is to keep Sketchpad around in the deployed app, but limit it to just super-duper-admins, if that helps.

[davestewart]

OK, so would you do something like this?

• https://laravel.com/docs/5.4/middleware#middleware-parameters

That way, just specifying a middleware should be enough.

If that's the case I guess either the settings or config approach would work?

[davestewart]

Having some more thoughts on this regarding configuration, roles, and general customisation.

At the moment, Controller Paths, Home and Help are all customisable, per user.

This being the case, it could be useful to use a Service Provider, potentially adding a place perhaps to customise exactly what is shown to each role.

For example, an Admin might see admin controllers, and a Super Admin might see super admin controllers, and each could see custom home and help views.

The Controller Paths section in Settings is going to get a modal in the next week or so to provide more control over each path (loading all methods in an iframe is the aim for this) but this could also be a good place to add per-folder middleware.

If you have any thoughts, please share them, or if you think this a bit of an overblown idea, I can stop ruminating 😉