[haiku-web] Re: Drupal-Trac Single Sign-On...
- From: "Jorge G. Mare (a.k.a. Koki)" <koki@xxxxxxxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Fri, 21 Mar 2008 10:32:34 -0700
Niels Reedijk wrote:
Hi Jorge,
So many questions!
2008/3/21, Jorge G. Mare (a.k.a. Koki) <koki@xxxxxxxxxxxxxx>:
Niels Reedijk wrote:
> Short update:
>
> 2008/3/21, Niels Reedijk <niels.reedijk@xxxxxxxxx>:
>> - Use an XMLRPC authentication mechanism. The Trac server will perform
>> a request whenever a login is taking place, and retrieves the details
>> of the user that way.
>>
>> I don't know if Unixware will allow 1. I should be able to write a
>> plugin for Trac for 2, and a quick google search shows that drupal
>> should already provide an XML plugin.
>
> I just wrote a plugin for Trac, and I think that part is done. I just
> need to hack drupal a little bit (currently only users with blog
> permissions can log in).
I think it is a mistake to hack Drupal for this purpose.
I do not agree at all with your assertion that this is a mistake or a
waste of time.
I never said that it was a waste of time.
I also do not agree that this is 'hacking' drupal in
the ferocious sense of the word you seem to be implying. Drupal has
been designed to be extended, and you should be glad it is designed
this way, as it enables the website to be the way it is today. Have a
look at the actual source code first, before claiming it's a big hack.
I never said it was a big hack; big or small, a hack is a hack.
What happens when we upgrade Drupal?
Big chance that nothing has to be changed. The plugin is in total 60
lines, of which 10 lines actual plugin (the others are hooks). I just
quickly glanced over a diff between the 4.7 version of blogapi (on
which the plugin is based) and the 6.0 version, and nothing in the
relevant part of the code has been changed.
Well, I am sure Waldemar thought he had all the basis covered when he
implemented the shared login, and as it turns out, he did not foresee
the problems that we eventually had. Chances are that the keeping shared
login will simply keep us vulnerable to such problems again in the future.
What if we need to move servers suddenly (like we had to once, and rendered
login unusable)?
The newer sollution is actually less dependent on the actual server,
and more dependent on the availability on www.haiku-os.org (or any
other host with Haiku's drupal installation on it). True, it is still
a dependency, but in fact this implementation is less dependent on the
actual physical location of the main site.
A dependency is a dependency. You are still making Trac vulnerable to
problems that may arise from changes on the website or to Drupal, some
of which you may not be aware of may not be able to foresee at all.
What if Niels is not available when any of this happens?
Well, if anything happens to Trac at all, I'd say you'd be lost. I'd
be willing to document an 'emergency scenario' if need arises, but it
would probably be better to start training a 'junior' website
maintainer.
And how does having any dependency (current or future) between Trac and
the website help (alleviate) the problem? What you are proposing is a
solution to a self-inflicted problem. The point is this: if we were
practical and wise, we could just drop shared login altogether: the
impact is insignificant, and we would have one less problem to worry about.
You guys keep repeating the same
mistakes and increase our vulnerability to this sort of situations (that
we have already experienced in the past, btw). All for what?
This approach does not increase the vulnerability in comparison to the
current situation. In fact, in the case of a server move, it decreases
the vulnerability.
That's not what I said. I am saying that this approach is vulnerable
compared to the alternative of not using shared login. This alternative
may not be ideal, but it makes the whole setup less vulnerable to one
system's problems affecting the other(s).
For a marginal (at the very best) one time gain in convenience?
Well, I don't really know how marginal it is, but I do like the gain
in convenience, and if it were possible, I'd try to add the subversion
repository authentication as well. What you imply knowing is exactly
how vulnerable the system is. What did you do, a complete system
analysis?
First, I am not talking about vulnerability in terms of security. I am
talking about any given system that you tie together becoming vulnerable
to break down because of a problem in another system. You don't need to
do a system analysis; it's common sense. Just remember how Trac broke
when the website was moved to a different server and you will understand.
Second, in the context of posting bug reports to Trac, having a one time
5 seconds requirement to register is insignificant. It's not like users
will be forced to go through a 10, 5, 3 or even 1 minute registration
process; it's just the time that it takes you to type a username, and
email and a password. In this context, the gain in convenience is marginal.
Finally, your idea of creating yet another dependency by adding
subversion to the mix simply adds to the complexity of the setup and the
probability of problems. Sure, it would be nice, but is it worth the
potential trouble? I don't think so.
What's more important, though, is: do you care?
Yes.
If that's the case, then please contribute to the discussion as a
process to reach a consensus first, before you start taking action on
your own. More on this below.
It looks like you don't,
since you are already moving full steam ahead in spite of the issues
that are being raised here.
I DO NOT agree with your assertion that I am moving full speed ahead
to anything. I have spent my morning solving a technical problem, by
looking at a possible set up. In the same spirit I've been looking at
a possible replacement for the current set up a few weeks ago, which I
tested on my private Trac installation for several hours
(http://www.trac-hacks.org/wiki/AccountManagerPlugin).
What's the point of trying to have a
discussion in a public discussion, if a single person is going to do as
he pleases anyway?
Jorge, stop the drama. Nothing has been *done* yet. Nothing has
actually been implemented on the server yet. I find the whole tone of
this message - as some of yours before - unneccesarily agressive and
completely out of context. I have spent my morning on a problem that
interested me, and I have come up with a solution that would give us a
choice between keeping the current login system or looking for a new
one. I am not going to forgive your ignorance on overestimating the
Trac login system - the truth is by default there is none. A little
investigation (or by just asking) would have revealed that. We will
always have to create a dependency on a non-standard module.
Please in future, if you do want to override people using rhetorical
figures, remember that this style (firing an array or rhetorical
questions) does not work using e-mail. I will tediously answer every
single one of them. Use arguments instead, next time.
All the knowledge and wisdom that you may have about the Trac login
system does not matter if you still make the system vulnerable to the
sort of breakdown that happened recently because of changes to the
website. This was real, and we can avoid it from happening again by
making a simple choice. You certainly know more than me about Trac, I
don't deny that. But that alone does not make your choice a better,
wiser or more more practical one.
Also, you are free to spend your time as you like; but if we are trying
to work as a team here (we are, right?), then before you go on your own
and spend so many hours on trying to resolve a technical problem, we
should first try to come to grips *as a group* on what exactly it is
that we need to do. If you start taking action before even a consensus
is reached (which it is what you are doing), then there is no point in
trying to have a discussion as a thought process to reach a decision.
Cheers,
Koki
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
