Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1365252 - No longer able to override network.negotiate-auth.trusted-uris
Summary: No longer able to override network.negotiate-auth.trusted-uris
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 24
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Horak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-08 17:22 UTC by Colin.Simpson
Modified: 2016-08-10 13:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-08-10 13:46:40 UTC

Attachments (Terms of Use)

Description Colin.Simpson 2016-08-08 17:22:24 UTC
Description of problem:

We usually override the network.negotiate-auth.trusted-uris on all our systems site wide by adding a list of sites with a list of internal sites we want to apply SSO Kerberos authentication to. 

We do this by pushing a file to /usr/lib64/firefox/browser/defaults/preferences called ion-prefs.js containing a line like (ours is a lot longer):


This now seems to get overridden by the entry in firefox-redhat-default-prefs.js:

pref("network.negotiate-auth.trusted-uris", "https://")

(weirdly this entry seemed to always be there in previous versions, just didn't seem to override our one)

This can be verified easily from about:config and the fact that SSO doesn't work in firefox now.

Version-Release number of selected component (if applicable):

Worked in firefox-47.0-4.fc24.x86_64 

Broke in firefox-48.0-5.fc24.x86_64

How reproducible:
Every time

Additional info:

Maybe there is a better place we should be putting out site wide prefs file that will properly override?

Was this broken by trying to fix bug #1349489, where it says your default entry wasn't being applied at all?

Comment 1 Jan Horak 2016-08-09 13:35:17 UTC
Thanks for the report! It seems that there's a conflict between configuration files (firefox-redhat-default-prefs.js and yours ion-prefs.js).  The issue did not happen in firefox-47.0-4.fc24.x86_64  because according to bug 1349489 the preference 'network.negotiate-auth.trusted-uris' was wrongly set therefore it did not apply.

I'll check what's the order of reading default preferences in /usr/lib64/firefox/browser/defaults/preferences/ later.

Comment 2 Jan Horak 2016-08-09 13:56:20 UTC
Since readdir which is processing the content of /usr/lib64/firefox/browser/defaults/preferences directory does not ensure any kind of order it might happen (and most likely it does in your case) that ion-prefs.js is processed first and later preferences are replaced by firefox-redhat-default-prefs.js.

To workaround this please move the 'ion-prefs.js' to the /etc/firefox/pref/ directory which is processed on the very end. That's the correct place for user configuration. It might be little less known and has been added recently.

This works for Fedora.

Comment 3 Colin.Simpson 2016-08-10 11:10:54 UTC
This does seem to work on F24 and also seems to work on RHEL 5,6,7, but not RHEL4 (we have a few straddlers still on that sadly) but not a big deal. Actually didn't check fully on RHEL4, there wasn't an /etc/firefox dir so, didn't even try.

This may also help with a firefox package update issue on RHEL6 we were seeing with our prefs file being at /usr/lib64/firefox/browser/defaults/preferences

So thanks for this is can close!

Comment 4 Jan Horak 2016-08-10 13:46:40 UTC
Thanks for the feedback. RHEL4 is not supported by Red Hat for quite a while therefore not receiving security updates of Firefox, so using system packages on RHEL4 is quite dangerous. Change that introduced /etc/firefox dir never made it to RHEL4, that's why there's missing /etc/firefox directory and even if you create it it won't work.

Note You need to log in before you can comment on or make changes to this bug.