Bug 961866

Can you include the relevant /var/log/httpd/access_log entries (scrub the username/password of course).

I ask only because I've just created a new user and then followed your steps and I definitely do not see this:

From /var/log/httpd/access_log:

192.168.25.50 - - [10/May/2013:10:14:10 -0600] "POST /ipa/session/json HTTP/1.1" 200 147
192.168.25.50 - - [10/May/2013:10:14:10 -0600] "GET /ipa/ui/images/ipa-banner.png HTTP/1.1" 404 306
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/reset_password.html HTTP/1.1" 200 2298
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/reset_password.js HTTP/1.1" 200 4245
192.168.25.50 - - [10/May/2013:10:14:27 -0600] "GET /ipa/ui/images/ipa-banner.png HTTP/1.1" 404 306
192.168.25.50 - - [10/May/2013:10:14:40 -0600] "POST /ipa/session/change_password HTTP/1.1" 200 205
192.168.25.50 - - [10/May/2013:10:14:53 -0600] "POST /ipa/session/change_password HTTP/1.1" 200 155

And from /var/log/httpd/error_log:

[Fri May 10 10:14:27 2013] [error] [client 192.168.25.50] File does not exist: /usr/share/ipa/ui/images/ipa-banner.png, referer: https://ipa.mydomain/ipa/ui/reset_password.html
[Fri May 10 10:14:40 2013] [error] ipa: INFO: WSGI change_password.__call__:
[Fri May 10 10:14:40 2013] [error] ipa: INFO: WSGI change_password: start password change of user 'jtest'
[Fri May 10 10:14:40 2013] [error] ipa: INFO: 200 Success: Password change was rejected: Constraint violation: Password is too short
[Fri May 10 10:14:53 2013] [error] ipa: INFO: WSGI change_password.__call__:
[Fri May 10 10:14:53 2013] [error] ipa: INFO: WSGI change_password: start password change of user 'jtest'
[Fri May 10 10:14:53 2013] [error] ipa: INFO: 200 Success: Password was changed.

Do you have debug logging enabled or something?  The above is from a stock IPA (no changes to apache config) using ipa-server-3.0.0-26.el6_4.2.x86_64.

As an aside, can you also double-check permissions on those files?  They should not be exposed to other users on the system; /var/log/httpd is mode 0700 and, while the files are mode 0644, due to the directory permissions they are not readable:

[root@ipa ~]# su - jtest
su: warning: cannot change directory to /home/jtest: No such file or directory
-sh-4.1$ cat /var/log/httpd/access_log
cat: /var/log/httpd/access_log: Permission denied
-sh-4.1$ cat /var/log/httpd/error_log
cat: /var/log/httpd/error_log: Permission denied

(In reply to comment #3)
> As an aside, can you also double-check permissions on those files?  They
> should not be exposed to other users on the system; /var/log/httpd is mode
> 0700 and, while the files are mode 0644, due to the directory permissions
> they are not readable:
> 
> [root@ipa ~]# su - jtest
> su: warning: cannot change directory to /home/jtest: No such file or
> directory
> -sh-4.1$ cat /var/log/httpd/access_log
> cat: /var/log/httpd/access_log: Permission denied
> -sh-4.1$ cat /var/log/httpd/error_log
> cat: /var/log/httpd/error_log: Permission denied

I'm sorry, I should have been clearer.  This happens when you proxy the password change site from another site. Here is a sample of the access log (the username and password are nonsensical):

172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /json2.js HTTP/1.1" 404 311
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /ipa.css HTTP/1.1" 404 310
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:25 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /password?username=2ewfwe&password=wef546u&new_password=j6786i7&verify_password=%2C78i67i6&submit=Reset HTTP/1.1" 200 2298
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /ipa.css HTTP/1.1" 404 310
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /json2.js HTTP/1.1" 404 311
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /reset_password.js HTTP/1.1" 404 320
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /images/ipa-logo.png HTTP/1.1" 404 322
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /images/ipa-banner.png HTTP/1.1" 404 324
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /jquery.js HTTP/1.1" 404 312
172.22.254.39 - - [10/May/2013:12:06:34 -0400] "GET /reset_password.js HTTP/1.1" 404 320



And here is the proxy pass configuration on the proxy webserver named my.proxyserver.biz:

           ProxyPass /password https://my.ipaserver.biz/ipa/ui/reset_password.html
           ProxyPassReverse /password https://my.ipaserver.biz/ipa/ui/reset_password.html
           RewriteEngine on
           RewriteRule ^/password/(images|javascripts|stylesheets)(.*) /password/$1$2

The idea is to not allow the average user to see the address of the IPA server while allowing them to change their password on the IPA server.

Ah, ok, that is clearer.  So the logging is taking place on your proxy server, not on the IPA server itself.

Looks like the solution would be to set the method to POST rather than not specifying it, which defaults to GET.

Thanks for all the info. I will open an upstream ticket requesting this change.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3623

I think there are two issues:

1) The main caused by the proxy: The reset_password.html page doesn't have access to all its dependencies - mainly JavaScript files. Therefore it doesn't use JavaScript code for issuing an asynchronous POST request to `ipa/session/change_password` and instead it uses implicit method - get request to the page url - the problem this ticket is about.

2) The form in reset_password.html doesn't work well with JavaScript disabled or with missing dependencies. Usually it's not a problem because it's expected that it will have access to its dependencies. Disabling JavaScript is a topic for completely different discussion.

I wanted to follow up to see if there was a patch I need to get in order to solve the problem or if it's still being worked.  Thanks.

There are no plans to fix it in near future because the situation can be easily avoided by properly configuring proxy as mentioned in #c8

Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.