Is there a way to configure to use local auth?


Is there a configuration setting so as to either disable authentication or do it locally rather than going through The server is slow and I really see no reason for me (and most likely most users) to have “serious authentication” when the typical person running SickRage will be doing so on a local computer that doesn’t even allow for out-of-LAN connections.



The SSO auth server is there not just for locking down the WebUI but also for creating access tokens to allow the app API access, the API facilitates cached provider search results that are pooled from every connected SR app instance, this allows us to provide instant search hits.

We will be getting a connection upgrade around the 27th that will resolve any slowness issues you may be experiencing now, if it doesn’t we will move the SSO server into the cloud to ensure constant access at data center speeds.


The cached provider search thing makes sense – I don’t mind that at all. So, there’s no way to divorce the WebUI auth from that (or have an option to do so) just so we don’t ever have to worry about being able to use the WebUI even if the official sickrage server is down, etc?


I have been kicking around an idea to have the app disable auth requirements only if becomes unreachable then require login once resolved, only issue is I’ve not found away around some of the security flaws in that idea as you can imagine this would open the doors wide for outside attackers to take advantage of such a thing.

TBH placing the server in the cloud may be the best way to ensure stability for this service but I’d like to give it a go first on my servers back here at home once the new connection is installed, as you can imagine proper cloud servers cost money and this is a open source project without any funding currently.


Yea, all of that makes complete sense for the app API access. I guess I just don’t see the reason why the requirement for the WebUI auth is tied up with it. I mean, I can see where it would be the default setting – but, it would make sense to me that there would be a setting where one could disable WebUI auth entirely.

If you considered something like this, then there wouldn’t be so much of a reason to worry about whether is down …because, if it was (i.e., if the app was unable to authenticate) then the user would just lose provider search (or perhaps just lose the “cached provider search results” feature.)

Anyway, I’m not trying to troll, be difficult, etc …I’m just throwing out some thoughts/suggestions. I’ve not looked into the code yet since I came back to the project, so it could be that what I’m proposing would be difficult and/or messy. :slight_smile:


I don’t find you difficult at all, debate breeds great ideas!

The auth server takes you’re credentials and uses them to generate a token that is then used with the API, also that same login is now used for the forums and GIT server as well as the members area that is coming soon for added premium features.

The way I see it is that having this brings a lot more value added services to the table then without it, take for instance a while back another fork was labeled to have a exploit that allowed attackers to jump into SR and steal their provider credentials, it was patched but had user/pass been enforced from the start this wouldn’t of been a concern at all.

Stabilizing the auth server is a priority of mine as I don’t want to see others affected by issues or downtime if it did go offline, having a instance of it here at the house and in the cloud can take care of outage issues.

I’m open to other suggestions and ideas :slight_smile:


Would be great if we can set a LAN range to allow local auth. No need to go to the web every time to authenticate. Don’t get me wrong I love SSO, and would also be very interested to integrate into my Azure AD to have real SSO between all my apps.


Thats another idea tossed around, allow local auth only after one has logged in for the first time to create the token for the API, there are still some security concerns with that approach as to how SR determines where it gets the IP address of the person accessing the app instance to properly validate it is in fact local and isn’t being faked.


I would also like to add that a feature to enable/disable SSO in the SickRage would be a huge pre in my paranoid brain. (that besised the issue i’m currently having with SSO redirection).


Thanks for the heads up. I’ll pass on using this program until it can all get localized.