[Freeipa-devel] [PATCH] [WIP] Firefox extension

[Rob Crittenden]

Petr Vobornik wrote:
> On 10/05/2012 05:30 PM, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Fri, 2012-10-05 at 17:33 +0300, Alexander Bokovoy wrote:
>>>> On Fri, 05 Oct 2012, Endi Sukma Dewata wrote:
>>>>> On 10/5/2012 8:56 AM, Alexander Bokovoy wrote:
>>>>>> On Thu, 04 Oct 2012, Petr Vobornik wrote:
>>>>>>> On 10/03/2012 04:19 PM, Simo Sorce wrote:
>>>>>>>> On Wed, 2012-10-03 at 15:50 +0200, Petr Vobornik wrote:
>>>>>>>>> As Alexander proposed in other channel. I will remove the
>>>>>>>>> removal of
>>>>>>>>> configure.jar and offer the old configuration method if user is
>>>>>>>>> using FF
>>>>>>>>> < 4 so we don't have to make the extension compatible with this
>>>>>>>>> ancient
>>>>>>>>> version. It will be done this way:
>>>>>>>>>
>>>>>>>>> If FF < 4 is detected:
>>>>>>>>>    * in browserconfig.html steps 2 and 3 will be grayed-out and
>>>>>>>>> replaced
>>>>>>>>> with step 2a with a link to ssbrowser.html and a description
>>>>>>>>> explaining
>>>>>>>>> the problem
>>>>>>>>>    * ssbrowser.html will be enhanced by steps for
>>>>>>>>> autoconfiguration
>>>>>>>>> of FF
>>>>>>>>> < 4.
>>>>>>>>>
>>>>>>>>> We can also show the steps in browserconfig, but I want to have it
>>>>>>>>> somehow available even if user is not using FF<4 to keep general
>>>>>>>>> awareness about the problem and also to be usable if version
>>>>>>>>> detection
>>>>>>>>> fails. Other possible problem with steps in browserconfig is
>>>>>>>>> different
>>>>>>>>> styles of buttons (to keep the same styles we would have to
>>>>>>>>> include
>>>>>>>>> same
>>>>>>>>> css files and jquery.js to configure.jar, which I don't want to
>>>>>>>>> do).
>>>>>>>>
>>>>>>>> Excellent plan, we should try to reduce the amount of work, and
>>>>>>>> letting
>>>>>>>> old browsers use the old method is perfectly fine.
>>>>>>>> If FF15 is the only browser that fails with the old method I
>>>>>>>> would even
>>>>>>>> go as far as testing exclusively with FF15 and have anything <
>>>>>>>> FF15 use
>>>>>>>> the old method.
>>>>>>>>
>>>>>>>> Simo.
>>>>>>>>
>>>>>>>
>>>>>>> Updated patches attached.
>>>>>>>
>>>>>>> browserconfig.html points to older config method for versions
>>>>>>> prior to
>>>>>>> 15.
>>>>>>>
>>>>>>> The extension is theoretically compatible with FF3.6 and then FF10
>>>>>>> and
>>>>>>> later. There is a problem for FF4-9 with loading strings from
>>>>>>> .properties file. FF3.6 is working because it doesn't use
>>>>>>> bootstraping.
>>>>>>>
>>>>>>> I also notice that we have an existing issue when navigating to
>>>>>>> config
>>>>>>> pages right away before accepting any certificate. Those pages are
>>>>>>> using some resorces from /ui/ folder which is redirected to https.
>>>>>>> These resources are not loaded because certificate isn't
>>>>>>> imported. If
>>>>>>> user is going straight for Web UI, he won't encounter this issue,
>>>>>>> but
>>>>>>> someone might.
>>>>>> I tested this patchset and apart from the non-obvious  extension
>>>>>> description displayed when installing it, which is based on a
>>>>>> certificate,
>>>>>> everything is great.
>>>>>>
>>>>>> ACK.
>>>>>>
>>>>>
>>>>> It works for me too. Just some questions:
>>>>>
>>>>> 1. It looks like the Firefox is limited to version 10 to 15 in
>>>>> install/ffextension/install.rdf. Do we need the upper limit?
>>>>>
>>>>>   <em:minVersion>10.0</em:minVersion>
>>>>>   <em:maxVersion>15.0.*</em:maxVersion>
>
> My understanding is that maxversion represents maximum tested version.
> [https://developer.mozilla.org/en-US/docs/Install_Manifests] but the
> document doesn't say if the extension stops being installable on newer
> versions.  I tried maxversion=14.0.* on FF15 and it worked.
>
>>>>>
>>>>> 2. In install/html/ssbrowser.html the step 5 is optional. Should we
>>>>> explain what's that for or why we need it? General users could be
>>>>> confused and stuck if they are given choices that they don't
>>>>> understand. It's probably better to make it a required step if it
>>>>> doesn't cause any problem.
>>>>>
>>>>>   <li> 5. Optional: Repeat the above procedure for the
>>>>> <tt>network.negotiate-auth.delegation-uris</tt> entry, using the same
>>>>> domain. </li>
>>>> delegation-uris setting should be removed. It is not needed since we
>>>> started using s4u2proxy mechanism.
>>>
>>> Yes and we removed it because it is potentially a dangerous setting.
>>> It should be generally discouraged and enabled only for specific fqdn's
>>> not wildcard ones in future.
>>>
>>> Simo.
>>>
>>
>> I've pushed these 4 patches to master and ipa-3-0.
>>
>> Petr, please submit a patch to remove/clarify references to
>> delegation-uris setting.
>
> Patch attached.
>
>>
>> rob
>
>

ACK, pushed to master and ipa-3-0

rob