[Support] IBRACORP - All images and files


Recommended Posts

Thanks for the tip, it was actually the IP problem, I put the unraid IP, when I should leave 0.0.0.0

Now I have another problem. I can log in into authelia, but every subdomain protected by authelia, I get 

403 Forbidden

nginx/1.18.0

 

I know is a permission problem, but I can't figure it out were is the setting. In the user_database.yml, my account have the groups -admin and -dev

Also I removed the # in the corresponding proxy-conf authelia section.

 

In the docker LOG it says time="2020-12-19T15:31:09-05:00" level=info msg="Access to https://sonarr.domain.com/favicon.ico is forbidden to user xxxxx" method=GET path=/api/verify remote_ip=xxx.xxx.xxx.xxx

Edited by chenci
Link to comment

Looks like I'm having the exact same issue with Radarr that some other folks were having, but I don't see a resolution for it in this thread.

 

I have reverse proxies set up for Sonarr and Radarr in NGINX Proxy Manager almost identically (both with a scheme of 'http'), with the only difference between their port. Both work great.

 

I began following this guide (which is fantastic, by the way - thank you) to set up Authelia and was successfully able to route Sonarr through Authelia on the first try.

 

However, when I perform the exact same steps with Radarr and Portainer (add the rules to the Authelia conf file, add Protected Endpoint conf block in the advanced tab for each proxy host in NPM), Authelia redirects the subdomain to http://radarr.subdomain.com instead of https://radarr.subdomain.com and throws an error. (I can access it just fine if I manually add an 's' to 'http' myself.)

 

Note that I've used the exact same Protected Endpoint conf as Sonarr, replacing only the container name for Radarr/Portainer.  I have no idea why Sonarr is the only one being automatically redirect to https right off the bat.

 

Edit: It looks like this is an NPM issue - I was able to resolve it using the recommended fix per this support thread.

 

Essentially, replace this line in OP's original config:

auth_request_set $target_url $scheme://$http_host$request_uri;

with this:

auth_request_set $target_url https://$http_host$request_uri;

 

Edited by HALPtech
  • Like 1
  • Thanks 1
Link to comment
On 9/5/2020 at 9:33 PM, TX_Pilot said:

A couple of ideas to keep things a bit cleaner.

 

1) I used environment variables available through NPM rather than hardcoding the ip and port into the Advanced Config.

 

So I made the following changes to the Protected Endpoint:


    set $upstream_CONTAINERNAME http://CONTAINERIP:CONTAINERPORT;

became:

    set $upstream_CONTAINERNAME $forward_scheme://$server:$port;
 

This will allow you to make the changes to IP/Port within NPM rather than both under the Details Tab and the Advanced Tab 

 

2) I also used the actual container name as well so that I don't have to worry about IP. All of the reverse proxy guides recommend you create a network and use the internal Docker network for your reverse proxy. If you do that then you can specify the container name instead of the IP.

 

So: 

    set $upstream_authelia http://SERVERIP:9091/api/verify;

became:

    set $upstream_authelia http://Authelia:9091/api/verify;

 

In this case Authelia is the name of my Authelia container.

 

I have found it is much easier to use container name and internal port references in your NPM config so that if you container IPs change you are stuck fixing your reverse proxy. Just make sure if you do this, your are using the container port, not the translated port for your UnRaid IP address.

 

With these changes you can almost use the same Protected Endpoint for each proxy host. The only thing that would be different is the CONTAINERNAME. I am not sure if it would be a problem for that to be the same between proxy hosts. I am going to do some testing and see if it matters.

 

--Scott

@TX_Pilot Can you explain a little more about how you achieve #2? With "creating an internal Docker network for your reverse proxy and specifying container names". Right now my whole system is in Bridge networking but I love the idea of using variables, as you have here... I'm sure there will be a reason my future-self will appreciate that.

Link to comment

Thank you everyone for all your contributions to this guide and helping me set it up. Everything is working fine on my end, however I'm trying to bypass Authelia when I'm on my local network, however it doesn't seem to be working.

 

my configuration.yml

default_policy: deny
rules:
  - domain: "*.domain.com"
    policy: two_factor
  - domain: "*.domain.com"
    policy: bypass
    networks:
      - 10.0.0.0/24

When I look at the logs and I'm connected to my LAN to access my domain name it shows up in my logs remote_ip = external_ip_of_domain. Did I misconfigure anything? I'm using swag container for my reverse proxy.

 

I have nat loopback/nat reflection enabled so I think what's happening is that it's returning back my server ip address.

Edited by bobokun
Link to comment
On 1/14/2021 at 6:20 AM, bpage said:

Has anyone had issues with this working on Safari and/or mobile safari? Everything seems to work ok in Chrome browser, but trying from Safari, either I do not get forwarded after authentication or my rules (allow local networks) do not work at all. 

 

Possible cookie issue? No real answer for you at this time from me never tested with Safari but are cookies being saved?

Link to comment
On 21.12.2020 at 21:45, HALPtech said:

Похоже, у меня та же проблема с Radarr, что и у некоторых других людей, но я не вижу решения для нее в этой теме.

 

У меня есть обратные прокси, настроенные для Sonarr и Radarr в NGINX Proxy Manager почти одинаково (оба со схемой http), с единственной разницей между их портом. Оба отлично работают.

 

Я начал следовать этому руководству (что, кстати, фантастически - спасибо), чтобы настроить Authelia, и с первой попытки смог успешно направить Sonarr через Authelia.

 

Однако, когда я выполняю те же самые шаги с Radarr и Portainer (добавляю правила в файл conf Authelia, добавляю блок conf Protected Endpoint conf на расширенной вкладке для каждого прокси-хоста в NPM), Authelia перенаправляет субдомен на http: // radarr .subdomain.com  вместо https://radarr.subdomain.com  и выдает ошибку. (Я могу получить к нему доступ, если сам вручную добавлю 's' к 'http'.)

 

Обратите внимание, что я использовал ту же конфигурацию Protected Endpoint, что и Sonarr, заменив только имя контейнера для Radarr / Portainer. Я понятия не имею, почему только Sonarr автоматически перенаправляет на https сразу же.

 

Изменить: похоже, что это проблема NPM - я смог решить ее, используя рекомендованное исправление для этого потока поддержки .

 

По сути, замените эту строку в исходной конфигурации OP:


с этим:


 

thank you guy))) it's work)) niceee

Link to comment
On 12/22/2020 at 5:45 AM, HALPtech said:

Looks like I'm having the exact same issue with Radarr that some other folks were having, but I don't see a resolution for it in this thread.

 

I have reverse proxies set up for Sonarr and Radarr in NGINX Proxy Manager almost identically (both with a scheme of 'http'), with the only difference between their port. Both work great.

 

I began following this guide (which is fantastic, by the way - thank you) to set up Authelia and was successfully able to route Sonarr through Authelia on the first try.

 

However, when I perform the exact same steps with Radarr and Portainer (add the rules to the Authelia conf file, add Protected Endpoint conf block in the advanced tab for each proxy host in NPM), Authelia redirects the subdomain to http://radarr.subdomain.com instead of https://radarr.subdomain.com and throws an error. (I can access it just fine if I manually add an 's' to 'http' myself.)

 

Note that I've used the exact same Protected Endpoint conf as Sonarr, replacing only the container name for Radarr/Portainer.  I have no idea why Sonarr is the only one being automatically redirect to https right off the bat.

 

Edit: It looks like this is an NPM issue - I was able to resolve it using the recommended fix per this support thread.

 

Essentially, replace this line in OP's original config:


auth_request_set $target_url $scheme://$http_host$request_uri;

with this:


auth_request_set $target_url https://$http_host$request_uri;

 

Thank you for this. I will update the conf file to address this issue going forward. 

Link to comment

Not sure if you changed something with your templates but as of this morning I started receiving this warning in my Fix Common Problems plugin and as soon as I press apply fix and rescan the error still persists showing that the url should be pointing to authelia. I think you have two templates (Jira service desk and Authelia) both pointing to Authelia docker?image.thumb.png.42d1214f77f928f706ac6b904aac0156.png

Link to comment

I'm in the process of switching my install over from the LetsEncrypt/SWAG container to NginxProxyManager for my reverse proxy. I had Authelia set up and working with SWAG and it appears that it should be working with NPM, but my protected endpoints are all exposed without authenticating through Authelia. I have been following the guide (although I have not set up Redis or MariaDB, if that is possibly relevant).

I am able to access Authelia at "auth.MYDOMAIN.ca" . I have copied the conf files to the advanced tabs for authelia and each of my endpoints needing protection, and edited them appropriately. When I try to access any of the "protected" endpoints via private browsing in FireFox or from outside my LAN, it bypasses authelia entirely.

Here is the Access Control section of my authelia configuration.yml:

access_control:
  # Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'.
  # It is the policy applied to any resource if there is no policy to be applied
  # to the user.
  default_policy: deny

  rules:
    - domain: "*.REDACTED.ca"
      policy: two_factor

 

I have tried configuring several different containers/endpoints (cloud9, ApacheGuacamol, sonarr) and they all seem to bypass Authelia.

 

Any suggestions on how to fix or troubleshoot would be much appreciated.

Link to comment
8 hours ago, bobokun said:

Not sure if you changed something with your templates but as of this morning I started receiving this warning in my Fix Common Problems plugin and as soon as I press apply fix and rescan the error still persists showing that the url should be pointing to authelia. I think you have two templates (Jira service desk and Authelia) both pointing to Authelia docker?image.thumb.png.42d1214f77f928f706ac6b904aac0156.png

Thank you again, appreciate you coming back here to report it. Indeed, the issue was the JIRA template had Authelia repository linked. Should now be fixed, if you could confirm that would be great. Changes should take effect within 2 hours.

Link to comment
1 hour ago, mikedm139 said:

I'm in the process of switching my install over from the LetsEncrypt/SWAG container to NginxProxyManager for my reverse proxy. I had Authelia set up and working with SWAG and it appears that it should be working with NPM, but my protected endpoints are all exposed without authenticating through Authelia. I have been following the guide (although I have not set up Redis or MariaDB, if that is possibly relevant).

I am able to access Authelia at "auth.MYDOMAIN.ca" . I have copied the conf files to the advanced tabs for authelia and each of my endpoints needing protection, and edited them appropriately. When I try to access any of the "protected" endpoints via private browsing in FireFox or from outside my LAN, it bypasses authelia entirely.

Here is the Access Control section of my authelia configuration.yml:


access_control:
  # Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'.
  # It is the policy applied to any resource if there is no policy to be applied
  # to the user.
  default_policy: deny

  rules:
    - domain: "*.REDACTED.ca"
      policy: two_factor

 

I have tried configuring several different containers/endpoints (cloud9, ApacheGuacamol, sonarr) and they all seem to bypass Authelia.

 

Any suggestions on how to fix or troubleshoot would be much appreciated.

I'm not too sure how much the redis or mariadb would impact it. 

It's more likely the NGINX config, another user has reported the same issue (https://github.com/ibracorp/authelia/issues/3) but for the life of me I don't see why 

Link to comment
1 hour ago, Sycotix said:

Thank you again, appreciate you coming back here to report it. Indeed, the issue was the JIRA template had Authelia repository linked. Should now be fixed, if you could confirm that would be great. Changes should take effect within 2 hours.

Can confirm it's fixed now! thank you

Link to comment

I have just recently stumbled across your Channel on YouTube and want to tell you that you are on to a winner here you have some great content already and look forward to upcoming videos.

 

a question is do you do requests?  i would love a upto date and supported container for Serviio if that is possible

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.