Access Tags without login

[mfnalex]

Hi, is it not possible to disable the user authentication? I want to create a publich dashboard, so basically:

1. Anyone can view the Dashboard without logging in
2. Only I can change it when logged in

Is this possible? I couldn't find anything related to this in the settings.

[arifer612]

Isn't this already possible with the "Allow public access to front" switch in the Users setting?

[mfnalex]

No, it doesn't let users click on Tags

[mfnalex]

See here and click on "My Spigot Plugins": https://hub.jeff-media.com/

I'd like the tags to be accessible by the public, too.

[062bel313]

I want to implement exact as shown in https://hub.jeff-media.com/. Some of tags to be public and some requires access. I guess for that I need some setting for each tag and I cannot find it. How to add authentication for some tags and not for others?

Am I missing something?

Where is the setting that if someone clicks on this tag (bitwarden) will ask for permission?

[mfnalex]

I want to implement exact as shown in https://hub.jeff-media.com/. Some of tags to be public and some requires access. I guess for that I need some setting for each tag and I cannot find it. How to add authentication for some tags and not for others?

Am I missing something?
Where is the setting that if someone clicks on this tag (bitwarden) will ask for permission?

How did you even manage to make your tags accessible to the public? All my tags are only available when I log in, which is the opposite of what I want.

[062bel313]

in the Heimdall, go to users >> username>> edit>> enable "Allow public access"

Not sure if you have it enabled, but that is what I have and it is access to public. But in my case all of them are access.

[arifer612]

@062bel313 I'm not sure what you meant by some tags being public. If you click on any of his tags, "My Spigot Plugins", "My Spigot Libraries", "Websites [German]", and "Internal", you will notice that you have to log in to his local account. All other links on the page however, are accessible through the normal browser because they point to public web pages.

@mfnalex, if you want all your tags to be accessible from the public, all you need to do is to create an account without a password and ensure that the "Allow public access to front" is checked as what @062bel313 mentioned above. If however, as what @062bel313 wanted, you want some tags to be public and some to be private, then I think the you should change the title to be something more descriptive.

[062bel313]

sorry for hijacking the thread.
@arifer612: In my case though, a user can click any tags and it lets them enter my local services without asking for a heimdall login; I have password set for the account. I want some to open but some require login. How is he doing that?
@mfnalex: you do not need account without password. You can have a password, but make sure you enable "Public access".

[arifer612]

@062bel313 I don't think you're hijacking the thread since it's relevant to OP's question. The thing I'm confused about is that you're saying that there are some tags in https://hub.jeff-media.com/ that are accessible by the public without having to log in, while from what I see, none of them are.

Are you perhaps treating his links as tags? For example in the image below, "Discord" is accessible by the public since it's a link whereas "My Spigot Plugins" isn't since it's a tag. With an account password and "Allow public access to front" checked, I can reproduce this without an issue.

​If you're comfortable with it, maybe you can share with us the link to your Heimdall page so that I can see whether or not I can access your tags.

[062bel313]

I see, i misunderstood links and tags. How can i put my internal server links within tags? Seems like i need to check more on tags, my bad.

On Wed, Aug 11, 2021 at 12:18 AM Arif Er ***@***.***> wrote: @062bel313 <https://github.com/062bel313> I don't think you're hijacking the thread since it's relevant to OP's question. The thing I'm confused about is that you're saying that there are some tags in https://hub.jeff-media.com/ that are accessible by the public without having to log in, while from what I see, none of them are. Are you perhaps treating his links as tags? For example in the image below, "Discord" is accessible by the public since it's a link whereas "My Spigot Plugins" isn't since it's a tag. With an account password and "Allow public access to front" checked, I can reproduce this without an issue. [image: image] <https://user-images.githubusercontent.com/46054733/128973264-9f4e5f89-3481-4bc0-bc48-c7ce50eef329.png> ​If you're comfortable with it, maybe you can share with us the link to your Heimdall page so that I can see whether or not I can access your tags. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABS3Y42BIAHGRPIJPMYNH53T4IBZ3ANCNFSM472M64NA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

-- Guna R. Bharati

[mfnalex]

@062bel313 I'm not sure what you meant by some tags being public. If you click on any of his tags, "My Spigot Plugins", "My Spigot Libraries", "Websites [German]", and "Internal", you will notice that you have to log in to his local account. All other links on the page however, are accessible through the normal browser because they point to public web pages.

@mfnalex, if you want all your tags to be accessible from the public, all you need to do is to create an account without a password and ensure that the "Allow public access to front" is checked as what @062bel313 mentioned above. If however, as what @062bel313 wanted, you want some tags to be public and some to be private, then I think the you should change the title to be something more descriptive.

I did that, and the tags are still not public :(

EDIT: Public Access is enabled for both users

[arifer612]

@062bel313
I suppose you have already created tags, if you have not, you can do so by clicking on the square with the tag icon above the settings cogs icon at the bottom right of Heimdall. Once you have created your tags, you can "move" applications into tags by selecting the appropriate tags when you edit them. For example, I have my Radarr application under the Media tag as shown in the image below.

[arifer612]

@mfnalex Aha, I faced that problem when I first tried it out too! Sometimes you might need to wait for the DNS to update its cache. Maybe you can check it on a private browser to see if the changes have been updated.

Another thing about your set up is that since jeff is the first user, by default, the page will show the dashboard for jeff. If you want it to show the dashboard for the user named public, you would have to set that as the first user. You can also change the user at the bottom left.

[mfnalex]

@mfnalex Aha, I faced that problem when I first tried it out too! Sometimes you might need to wait for the DNS to update its cache. Maybe you can check it on a private browser to see if the changes have been updated.

Another thing about your set up is that since jeff is the first user, by default, the page will show the dashboard for jeff. If you want it to show the dashboard for the user named public, you would have to set that as the first user. You can also change the user at the bottom left.

What does DNS have to do with this? Anyway, I set the DNS records like months ago, so that cannot be the problem. I also tried in incognito mode, the tags are not accessible, just see for yourself :) https://hub.jeff-media.com

[arifer612]

I don't see the option to change the user to the "public" user that you created earlier. And if you set a password to your account, the tags will not be accessible unless you're logged in.

[062bel313]

After I create an account with password, and allow it public, then I created tags moved my web services inside the tags, then I no longer can access those which are inside tags. For my use case that is exactly what I wanted, so I need to put links inside tags that I do not want public access and all others in the home dashboard for public access.

@arifer612 : I only have 1 account with a password set and public access enabled. In my case all the links in "Home Dashboard" tags are open to public, and anything under other tags, such as "Media" I created requires authentication. On your side I guess you want to give access to tags for public, seems like we cannot do that.

[mfnalex]

Seems like I'll have to setup "subinstallations" of heimdall to accomplish what I need - just a simple dashboard without any access restrictions :/

[mfnalex]

maybe a config option for each tag could be added whether it's owner-only or public, would be nice

[062bel313]

I agree with @mfnalex, configuration with access restrictions for each tags and links would be a nice.

[arifer612]

If you're still looking for a solution to this, I have found a method to do just that using Authelia. It works well with the linuxserver/swag image so if you're reverse proxying and not using that image, I suggest you take a look at how they integrate Authelia into the configuration files.

Back to how I pulled it off, I first removed the password for my only user on Heimdall since Authelia will handle all the authorisation.

Heimdall setup

I have 3 groups of users with different permissions planned out:

1. Admin
2. Dev
3. Users

Each of these groups will have access to different tags in my Heimdall instance. I have Heimdall set up to launch at domain.org, heimdall.domain.org, and www.domain.org. It is set up with multiple tags; some I wish to be accessible by general users and some by devs, and all others to the public.

I now have to make sure that Authelia will handle the authorisation of the tags by including the following in the heimdall.sub*.conf file:

# Heimdall tags protected by Authelia
location /tag/ {
    # enable the next two lines for http auth
    #auth_basic "Restricted";
    #auth_basic_user_file /config/nginx/.htpasswd;

    # enable the next two lines for ldap auth
    #auth_request /auth;
    #error_page 401 =200 /ldaplogin;

    # enable for Authelia  <-- THE LINE UNDER THIS HAS TO BE ADDED
    include /config/nginx/authelia-location.conf;

    include /config/nginx/proxy.conf;
    include /config/nginx/resolver.conf;
    set $upstream_app heimdall;
    set $upstream_port 443;
    set $upstream_proto https;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}

Authelia setup

Authorisation will be done with a simple password managed using a local user-database so the policy is one_factor. To define the permission groups in Authelia, the relevant segment of the configuration.yml file reads:

  rules:
    ## Rules applied to 'admin' group
    - domain:
        - domain.org
        - heimdall.domain.org
        - www.domain.org
      resources:
        - "^/tag/secretstuff$"       ### The tag named internal
      subject: "groups:admin"
      policy: one_factor

    ## Rules applied to 'dev' group
    - domain:
        - domain.org
        - heimdall.domain.org
        - www.domain.org
      resources:
        - "^/tag/internal$"           ### The tag named internal
        - "^/tag/management$"  ### Tag named management
      subject: "groups:dev"
      policy: one_factor

    ## Rules applied to 'users' group
    - domain:
        - domain.org
        - heimdall.domain.org
        - www.domain.org
      resources:
        - "^/tag/media$"          ### The tag named media
      subject: "group:users"
      policy: one_factor

   ## Rules applied to the public
   - domain:
       - domain.org
       - heimdall.domain.org
       - www.domain.org
      resources:
        - "^/tag/.*$"                ### All other tags
      policy: bypass

Breaking them down, only members of the admin group can access the tag 'secretstuff'; members of the dev group can access the tags 'internal' and 'management'; members of the users group can access the 'media' tag; and all other tags are publicly accessible.

Added precautions

Naturally, I also had to make sure that I add on the proper access rules for the web apps that are supposed to be behind the tags. For example, I may have Grafana that is accessible at grafana.domain.org that is sitting behind the 'management' tag which is accessible to members of the group dev. My Grafana reverse proxy configuration will look like this:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name grafana.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia  <-- THE LINE UNDER THIS HAS TO BE ADDED
    include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia  <-- THE LINE UNDER THIS HAS TO BE ADDED
        include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app Grafana-Unraid-Stack;
        set $upstream_port 3006;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
        
        # Clear Authorization Header if you are using http auth and normal Grafana auth
        #proxy_set_header    Authorization       "";        

    }
}

The access rules added to the Authelia configuration.yml to reflect this change would then be:

    - domain: "grafana.*"
      subject: "group:dev"
      policy: one_factor

Benefits

The one benefit you get from using this approach is that you now have a single sign-on authentication that covers your whole domain and is configurable to do everything you want to. The values for the domain keyword in configuration.yml can be regexp, amplifying your rules specification however you see fit.