PHP Authentication vs Basic

Customization & Special Requests
, ,
#1

Looking into implementing a PHP authentication system and storing the credentials in an SQL database.

My question is this. How is it currently requesting basic authentication when accessing services on a different port? For example, I know plex web server listens on port 31400, but it’s still asking for my login details when access that (the apache login details, not the plex ones). How is apache setup to intervene in this scenario?

I’ve also noticed that CSF doesn’t ask for these details and instead just serves it’s own login page. Why is CSF different to apache?

Would a PHP login system still be viable in this case? If there is something between plex and the user that is asking for authentication, could I drop something in there, say a page that checks if the user is already authenticated before serving up the contents? I don’t want to just insert a redirect page, as if the user gets hold of the resulting URL, they could easily by pass this.

Hope I make sense. This isn’t exactly my expertise.

#2

Check out the .conf files that are created to handle forwarding. These are located at /etc/apache2/sites-enabled/. Within you will notice lines such as :

<Location /{$application}>
ProxyPass http://localhost:{$port}/{$application}
ProxyPassReverse http://localhost:{$port}/{$application}
AuthType Digest
AuthName "rutorrent"
AuthUserFile '/etc/htpasswd'
Require user ${username}
</Location>

If you do not want this digest authentication to occur on apps, you can simply change your .conf to the following example:

<Location /{$application}>
ProxyPass http://localhost:{$port}/{$application}
ProxyPassReverse http://localhost:{$port}/{$application}
Require all granted
</Location>

It’s standard and very basic (but effective) browser based digest auth. Password are hashed and stored within the /etc/htpasswd file.

Well, because like you… the creators of CSF wanted to use database authentication as well. The applications you see with the additional layer of authentication are the ones that we created forwarding configs for.

Plex already has a login page, not quite sure I am understanding. If you would like a global GUI login page that stores salted passwords in a database that must be accessed first and before access to additional application logins are even remotely permitted… then yeah… a php login system could be beneficial. Now, as to which method is better… storing via php file or an actual database? Probably the same results and one resulting is less frustration. :wink:

#3

Reason I’m looking into it is because it seems every user can access each others download files by simply changing the url. My guess is because basic auth only requires a valid user, and every user is valid, so every login is valid for every location. Having a sql based auth system would allow different levels of access.

Some one else mentioned spotting this bug in one of the other categories.

It would also fix the issue of going to plex and getting prompted for login credentials, even when you’ve arrived there from the dashboard (which you’ve already authenticated for).

I get the feeling nginx might have something to solve this, but I need to look into it more.

#4

Nginx does offer a solution to this. However; youd need to take into consideration it’d be a pretty extensive rewrite of the current QuickBox script and code. Although I do make this sound like a buzz kill, here is something you should keep in mind (and if you’d like to help… this would be amazing as I am always pressed for time these days :wink: ).

QuickBox is currently planned to make use of both Database Authentication as well as a GUI installer from a zip package (archived via the git repositories so it maintains semantic versions as usual and rolling updates will still be possible and entirely optional). With this there is an additional inclusion of the nginx webserver… so the goal is to have options, ie; apache -or- nginx 1/2

That bug has been reported and should had been solved… I’ll take a look at that… but again, the sole focus currently to QuickBox has it’s intentions gearing towards single user experience and not multi-user… it was literally just an added bonus :blush:

In upcoming versions, there are plans to adjust and enhance the script in it’s entirety. It’s a big campaign and we’ll all see how it goes. For now priorities are focused on launching the new website for QuickBox with lots of convenient bells and whistles, which are overdue and incredibly needed.

###Post Script
I tell you all this b/c it’s 100% relevant to your thoughts. :slight_smile:

#5 
Alias /liara.rtorrent.downloads "/home/liara/torrents/rtorrent/"
<Directory "/home/liara/torrents/rtorrent/">
  Options Indexes FollowSymLinks MultiViews
  AuthType Digest
  AuthName "rutorrent"
  AuthUserFile '/etc/htpasswd'
  Require user liara
  AllowOverride None
  Order allow,deny
  allow from all
  php_admin_value engine Off
</Directory>

Note the Require user liara. If user is not in the required section, they will be denied access. If your aliases say Require valid-user then you are using a very old version and should consider upgrading to a current version, as the update process should take care of that.

This re-auth is typically because you are switching from https to http, which contain different auth cookies.

1 Like
#6

Just checked all the config files and they are all set to be require {username}, so that looks fine.

Thanks for the information.