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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to