Disable SSOWat for custom URL

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
    ]
 }
}
1 Like

Do you think this could be applied to redirect a different domain to a 2nd server instead of a subdomain ? See How to have two Yunohosts servers at home?

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.

Thanks, I’ll try that