Allow bypassing simplesamlphp in developer mode #82

New Issue

oysteikt · 2025-03-19T00:17:48+01:00

oysteikt commented

2025-03-19 00:17:48 +01:00

grrr I wanna develop protected pages without even having to

oysteikt added the feature request ui/ux labels 2025-03-19 00:17:48 +01:00

oysteikt commented

2025-12-16 21:06:24 +01:00

There seems to be two approaches here:

We create some sort of PHP variable in the config that lets us bypass the call to $as->requireAuth();. It's not entirely optimal, because the website now acts differently than in prod, also there is no concept of who is logged in. Are they admin, or a normal user? What if you want to see the page as if you were not logged in? We could create debug toggles for all of these, but it's really not optimal
We setup simplesamlphp so that we create a dummy idp locally while debugging, and add it to the list of authentication sources (see dist/simplesamlphp-authsources.php). This is probably better, but it's more hassle up front. Also, I can't seem to find any documentation or blogposts about installing an idp locally as a dev/testing instance, only documentation recommending you to put your stuff in /var 💀. Are no one really doing this?

There seems to be two approaches here: 1. We create some sort of PHP variable in the config that lets us bypass the call to `$as->requireAuth();`. It's not entirely optimal, because the website now acts differently than in prod, also there is no concept of who is logged in. Are they admin, or a normal user? What if you want to see the page as if you were not logged in? We could create debug toggles for all of these, but it's really not optimal 2. We setup simplesamlphp so that we create a dummy idp locally while debugging, and add it to the list of authentication sources (see `dist/simplesamlphp-authsources.php`). This is probably better, but it's more hassle up front. Also, I can't seem to find any documentation or blogposts about installing an idp locally as a dev/testing instance, only documentation recommending you to put your stuff in `/var` 💀. Are no one really doing this?

oysteikt added reference local-dev-idp

2025-12-17 07:12:32 +01:00

oysteikt self-assigned this 2025-12-17 07:44:07 +01:00

oysteikt commented

2025-12-17 09:17:26 +01:00

I tried going with option 2, and it's mindbogglingly difficult...

Apparently, you can't just make a copy of the simplesamlphp that comes with composer and install its public dir into the www just like the other one, because composer flattens out the vendor dirs of its dependencies and autogenerates an include script which just so happens to be statically rendered (see vendor/autoload.php). So when you copy vendor/simplesamlphp to vendor/simplesamlphp-idp, it just never gets included, and you'd have to create your own include script to do so. The symptom of this is that the idp complains that it cannot find its config. Composer does not support having multiple copies of the same dependency, so we might just have to pull down the idp variant of simplesamlphp from a different source...

I tried going with option 2, and it's mindbogglingly difficult... Apparently, you can't *just* make a copy of the simplesamlphp that comes with composer and install its `public` dir into the `www` just like the other one, because composer flattens out the vendor dirs of its dependencies and autogenerates an include script which just so happens to be statically rendered (see `vendor/autoload.php`). So when you copy `vendor/simplesamlphp` to `vendor/simplesamlphp-idp`, it just never gets included, and you'd have to create your own include script to do so. The symptom of this is that the idp complains that it cannot find its config. Composer does not support having multiple copies of the same dependency, so we might just have to pull down the idp variant of simplesamlphp from a different source...

oysteikt commented

2025-12-17 10:00:48 +01:00

It is seemingly possible to configure simplesamlphp both as a service provider and an idp at the same time, and have the service provider request auth from this idp. That would solve the two-deps problem, as well as only require us to keep a single dev config. Trying some more