Simo Sorce wrote:
> ----- Original Message -----
>> From: "Rob Crittenden" <rcritten(a)redhat.com>
>> To: "Ipsilon" <ipsilon(a)lists.fedorahosted.org>
>> Sent: Tuesday, May 5, 2015 2:13:48 PM
>> Subject: Patches pending review
>>
>> Here is a list of the patches I have pending review:
>>
>> ticket 35:
>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>
> This one looks good but seem to need a rebase, cherry-pick barfs.
Rebased.
>
>> ticket 90:
>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/log/?h...
>
> I've had no time to look at this one yet.
>
>> ticket 111:
>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>
> This is reaaaallly ugly, can we rather have a config option we look for and not
enable sssd
> if this optoin is not set ?
> This way you *can* enable/disable it via the admin UI, which is handy if you are
testing
> stuff as an admin, you just shouldn't be able to change the configuration. (mark
the module
> cnfiguration with a "read-only" property somewhere ?
No argument there about the ugly. I was trying to avoid creating a whole
new mechanism to manage this one plugin, and I think I was looking at
enable/disable differently.
So I was looking at a much lower level, where disabling the plugin would
actually unconfigure it in sssd, apache, etc rather than just having the
info plugin not fire when a user authenticates. Configure is similar. If
the plugin was enabled at install time then one can turn it on/off but
if not, you're stuck.
The other complicating factor is that the same enable/disable code gets
called both by the UI and during startup, so some state information is
needed to know whether one can properly allow it or not.
I can see about setting a config option during install that would
indicate whether the underlying plumbing is configured or not and
perhaps base enable/disable requests on that. I'll take a look.
>> ticket 116:
>>
https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit...
>
> I think we shouldn't really allow non-mutual auth, if that check is because
mod_auth_gssapi
> fails to reutn the token on a 200 OK, then we just need to require a new enough
> mod_auth_gssapi, Ifixed that bug in master a couple of weeks ago, and can make a
release
> if necessary.
Yeah, that'd be great. In the meantime I'll pull the upstream source and
do some local testing.
I tested upstream release 1.2.0 and mod_auth_gssapi is still not sending
back a header for mutual auth when auth succeeds.
rob