SOLVED "authentication required" on User Portal

[wardmundy]

So the "broken" (and yes it is broken) recording interface digest authentication will stay. Why do I say it's broken? Because it doesn't prevent anything. If you click cancel you can still get to the login page. If you enter the credentials you still get to the login page. I dont understand the point in the brokenness of this.

It isn't broken. All current releases of PIAF work properly. Hitting the Cancel button when the Apache authentication prompt appears for ARI yields:

If someone is missing ari.conf in /etc/pbx, then they have either removed it or they are running a verrrrrrry old version of PIAF. In either case, running update-programs followed by update-fixes will restore their setup to proper operation.

 

[tm1000]

Yes I know.

tm1000, I apologize. I should not have jumped in here and I do not have a solution to the original problem. My rant is about nonsensical "answers" in a language barely resembling English that are no help to anyone. Obviously, I'm not speaking about you or Ward here.

 

[tm1000]

Ok so recordings requires the maint user and password. I guess thats what I've always been confused about. Seemed like at some point people would get prompted by that but then hit cancel and could log in

All current releases of PIAF work properly. Hitting the Cancel button when the Apache authentication prompt appears for ARI yields:

If someone is missing ari.conf in /etc/pbx, then they have either removed it or they are running a verrrrrrry old version of PIAF. In either case, running update-programs followed by update-fixes will restore their setup to proper operation.

 

[wardmundy]

As we have suggested before, for people that just want ARI, a system administrator could walk by their PC and enter and save the maint credentials for posterity. Then a link to ARI could be provided without exposing the rest of FreePBX. No it's not secure. But security doesn't seem to matter much to some folks anyway.

 

[tm1000]

Ok. Thanks for the clarification!

As we have suggested before, for people that just want ARI, a system administrator could walk by their PC and enter and save the maint credentials for posterity. Then a link to ARI could be provided without exposing the rest of FreePBX. No it's not secure. But security doesn't seem to matter much to some folks anyway.

 

[Twilight Sparkle]

How can you tell? Unintelligible English and two unexplained screen shots are all I see. One of those screen shots appears to open the whole web server to unauthenticated access.

well, its not open to the [ WHOLE WORLD ] if its not a open IP ADDRESS [ DMZ ] unless you are using a open IP and or DMZ to that PBX, then you have issues, but any way its just the Voice Mail access area not much they can do but listen to VM, do a call back OMG that it scary, but not everyone cares about that stuff in fact some people want it to be open if they want there friends to have access, i guess another thing they could have done is Change the access to another user file and tell the customers or users or friends that for [ security reason ] we require 2 Logins! 1. for customer access [ like an apartment door with the buzz in & then 2. your login ] it makes them feel all warm inside!

im not trying to be a Bad Pony here, but its cool to have other options!

 

[Hyksos]

For the Nth time, here is what you need to do for the ARI to function without having any http auth prompt and still protect the rest of the admin GUI.
If this does not work you either did not do "service httpd restart" or you messed something else while trying to fix it another way or your own way.

Edit /etc/pbx/httpdconf/ari.conf
this:

#Password protect ARI interface
<Directory /var/www/html/recordings>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /usr/local/apache/passwd/wwwpasswd
Require valid-user
</Directory>

Becomes:

#Password protect ARI interface
#<Directory /var/www/html/recordings>
#AuthType Basic
#AuthName "Restricted Area"
#AuthUserFile /usr/local/apache/passwd/wwwpasswd
#Require valid-user
#</Directory>

(all commented out)

Edit /etc/pbx/httpdconf/pbx.conf
Insert this in the file:

#Allow critical assets for ARI
<Directory ~ "^/var/www/html/admin/assets/(js|images|css)">
Satisfy Any
Allow from all
</Directory>

(Allow critical assets for ARI)

Do service httpd restart
Access the ARI without http auth prompt.

Do not expose the PBX webserver to the Internet under any circumstances, with or without such a modification.
If you have problems with this or something else, sue me, I own a leather sofa, a cigar, a glass of scotch and I'll be waiting for you enjoying all three.

 

[darmock]

While I am a proponent of "Big Button Technology" (ie: push a button and make it work linux godhood status not required) I really hate to release a "button" that would disable this stuff. Unfortunately you SHOULD know what you are doing when you disable a security paradigm and all of the ramifications. Unfortunately if a "button" was released people would use it willy nilly without understanding and then the S**T would hit the fan and all fingers would point back at the PIAF devs. I can automate the whole mess as above but .........

The PIAF Devs worked really hard on the current security paradigm and stand by it and use it every day.

Tom

 

[Hyksos]

The only thing that I need clarification on is what Hyksos posted above, I don't understand the ramifications of this line:
Code:
<Directory ~ "^/var/www/html/admin/assets/(js|images|css)">
My system does not have such a line and access to the ARI does not appear to need it. If it is necessary, is there any reason why this would not work:

The ARI needs to be able to load jquery from the js folder in the assets folder... same for images and css.
If you do not allow all the admin folder without auth, or all the assets folder without auth or each of those three in its own directive or use what I suggested... Accessing the ARI even after you removed the auth for /recording will open a prompt when the code tries to load stuff from js images and css folder as demonstrated many times in a browser's dev tool.

Cached creds in the browser for /admin... will render the test scenario invalid since you will not get the prompt after you have only removed auth for /recording.
Since when the prompt would appear for /admin/assets/js|images|css... your browser will use the cached creds for /admin to access it.

So I'd say lgaetz, you had some cached creds for /admin when you did not get further prompts after only removing auth for /recording in ari.conf. Or you already have removed auth for those three folder but each in their directory directive.

 

[tm1000]

The final fix for all of this will most-likely still be in 2.12 and yes we will work directly with darmock and wardmundy to make sure the end solution works well for them and the users as well. I would say for now it's moot. Although I am willing to push through whatever needs to be fixed in ARI, though I thought we already put all of the ARI assets in the recordings folder...

 

[mcbsys]

This may have been discussed ad infinitum, but it's always new to someone, and this thread is a top Google result.

I'd have to agree that it is counter-intuitive that by default, end users need admin privileges to access their ARI panel. If that is cached in their browser, what is to stop a curious/disgruntled employee from getting in to the main admin area and deleting trunks and extensions?

Re. the "Big Button" solution, how about a compromise: add a button to enable access to the ARI from within the local subnet? An "Advanced" option could allow listing subnets.

I needed access from two subnets. With help from lgaetz and Hyksos, here's what worked for me with PiaF 2.0.6.2 Brown, FreePBX 2.11.0.24, Asterisk 1.8.11-cert2:

/etc/pbx/httpdconf/ari.conf

#Only allow access to ARI from trusted subnets
<Directory /var/www/html/recordings>
Deny from all
Allow from 192.168.50.0/255.255.255.0
Allow from 192.168.100.0/255.255.255.0
</Directory>
 
#Allow critical assets for ARI
<Directory ~ "^/var/www/html/admin/assets/(js|images|css)">
Satisfy Any
Allow from 192.168.50.0/255.255.255.0
Allow from 192.168.100.0/255.255.255.0
</Directory>

In the second block, you do need Satisfy Any. Per the Apache docs, Satisfy is only needed when you're using both Require and Allow. And in fact, /etc/pbx/httpdconf/pbx.conf does have a "Require user wwwadmin maint" on the /admin directory. Basically the Satisfy Any is saying you can have access to these specific /admin subdirectories by providing the wwwadmin/maint password OR by coming in from a listed subnet. Satisfy Any is not needed in the first block because there is no other definition for the /recordings folder, i.e. there is no Require directive.

 

[MacNix]

Are there particular versions/flavors that this step might cause problems with??
specifically, i'm on purple, 2.9.0.14, with asterisk 1.8.4.1... any issues running this (aside from the obvious "you're letting anybody on your network gain user-access to your system")?

tx

Dave

This may have been discussed ad infinitum, but it's always new to someone, and this thread is a top Google result.

I'd have to agree that it is counter-intuitive that by default, end users need admin privileges to access their ARI panel. If that is cached in their browser, what is to stop a curious/disgruntled employee from getting in to the main admin area and deleting trunks and extensions?

Re. the "Big Button" solution, how about a compromise: add a button to enable access to the ARI from within the local subnet? An "Advanced" option could allow listing subnets.

I needed access from two subnets. With help from lgaetz and Hyksos, here's what worked for me:

/etc/pbx/httpdconf/ari.conf

#Only allow access to ARI from trusted subnets
<Directory /var/www/html/recordings>
Deny from all
Allow from 192.168.50.0/255.255.255.0
Allow from 192.168.100.0/255.255.255.0
</Directory>
 
#Allow critical assets for ARI
<Directory ~ "^/var/www/html/admin/assets/(js|images|css)">
Satisfy Any
Allow from 192.168.50.0/255.255.255.0
Allow from 192.168.100.0/255.255.255.0
</Directory>

In the second block, you do need Satisfy Any. Per the Apache docs, Satisfy is only needed when you're using both Require and Allow. And in fact, /etc/pbx/httpdconf/pbx.conf does have a "Require user wwwadmin maint" on the /admin directory. Basically the Satisfy Any is saying you can have access to these specific /admin subdirectories by providing the wwwadmin/maint password OR by coming in from a listed subnet. Satisfy Any is not needed in the first block because there is no other definition for the /recordings folder, i.e. there is no Require directive.

 

[mcbsys]

Updated my post to show my setup: PiaF Brown 2.0.6.2, FreePBX 2.11.0.24, Asterisk 1.8.11-cert2.