There are multiple posts [1] [2] [3] that are related to this topic, but all of them were in the context of apps but this is not.
I am attempting to allow a .well-known URL without SSOWat. This is a custom URL that is created on the root domain ( read : out of the scope of YunoHost ).
I tried putting the URL in permissions.core_skipped.uris both as a regex and as URL ( which is not what I want though ). I put it both in /etc/ssowat/conf.json.persistent as well as /etc/ssowat/conf.json. None of that worked.
Then I thought it could be a problem with my regex ( even though a hard-coded URL did not work either ) so I tried to retrieve the .well-known/autoconfig/mail/config-v1.1.xml path. That took me to the SSOWat page too.
But I know that .well-known/acme-challenge works because TLS certificates can be issued and renewed on the domain.
Is this something I am doing wrong in the configuration? How can I skip one URL path / regex from the SSOWat configuration?
PS : This is not a problem with the file path or the nginx configuration because it works fine if I disable the access_by_lua_file /usr/share/ssowat/access.lua.
after digging through the code of SSOWat, I realized I was being confused because the permissions manager was reworked in YunoHost 4.1. There were multiple references to using skipped_urls and unprotected_urls on this forum which led me rogue.
The other realization that I got while browsing through the code was that the permissions manager could take arbitrary names and was not limited to the apps installed on YunoHost ( which had initially misled me to using core_skipped which actually broke the core system ).
For future readers, you need to add an arbitrary permission in /etc/ssowat/conf.json.persistent as follows :
"permissions" : {
"arbitrary_permission_name" : { // can be anything
"auth_header" : false, // optional; what is the point anyway?
"public" : true, // required to skip the URIs being SSO'd
"show_tile" : false, // optional; to skip showing a tile on the user portal
"uris" : [ // required; the most important block
"sub-domain.domain.tld/path/to/resource",
"re:^[^/]*/%.well%-known/regex/too" // can take lua or PCRE regexes too
]
}
}
Disclaimer : I had sent a response to this post via email, but it was not delivered. Apparently, there are multiple problems including this one [1] with the Discourse instance hosting this forum.
The response I sent is below :
For redirects, you could use the redirected_urls block. You do not have to go through the pain of setting up the permissions block which can be complicated if you are not technically savvy / understand what the nested blocks / keys inside the permissions block does.