[haiku-web] Re: Drupal-Trac Single Sign-On...
- From: "Niels Reedijk" <niels.reedijk@xxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Sun, 23 Mar 2008 09:28:11 +0100
Hi Curtis,
2008/3/23, Curtis Wanner <katisu@xxxxxxxxxxx>:
>
> Jorge wrote:
> > What happens when we upgrade Drupal?
>
>
> This is not a major problem if he is actually writing an extension. Worse
> case is the link gets broken and we are back to square one with separate
> logins. Granted, I assume a fix would have to be done on trac.
>
> Quite honestly, I'm not impressed with the idea that trac will be dependent
> on haiku-os.org to be up for it to allow users to login. Can it be set up
> that registration happens through haiku-os.org and then updates be made only
> when users update their profiles? I would think it would generate less
> traffic that way too.
Well, it does not generate constant traffic. The design of Trac is as
follows: in essence, it is an open system. Anyone can contribute. If
people want to be remembered by a certain user name, with a certain
e-mail address, they can store that information in their session. This
is stored in the session table, and the user data is recalled using
cookies.
Now, of course there are users with more privileges. They can have
accounts. These aren't accounts in the Drupal (or Bugzilla) sense of
the word. They are simply predefined session data stored in the
database. Using http authentication, Trac knows that there is a
specific user, and then sends him/her a cookie with the session id.
with that cookie, Trac retrieves the stored information from the
session table.
This is essence means that Trac's design is ... different. Because it
has no notion of users, every operation has the user name stored,
instead of a reference to a real user. This is great for very open
systems, but we have closed it up considerably. So for us, this design
actually is not so efficient.
The current login method we use does this: it hijacks the login
procedure. It connects to the drupal database, authenticates a user
against that database, and then collects the user name and stores the
email address in the session table. During subsequent calls, the email
address is maintained and updated.
> I'm also of the opinion that this is marginal convenience. From what I've
> seen, the people that are serious about reporting bugs would register
> anyway. If anything, the shared login seems to have encouraged some people
> to report bugs with very sketchy information or ask for weird enhancements.
> I don't know, maybe that would exist regardless.
>
> While Jorge may be overreacting a bit, I tend to agree with the general idea
> of his comments. Before making the changes, it should be thought out the
> possible consequences of these changes. I for one was not too happy that
> adding comments on trac was broken for a while. That certainly didn't
> encourage or help people to add bug reports and information did it? At the
> very least, I hope Niels has a free schedule to fix problems if he does
> implement this shared login. I'd rather not see a prolonged period with
> login problems.
Just minor correction here: that the commenting was broken was not
caused by the login system. It was a bug in a template that
miraculously surfaced. I still don't know why.
> While I appreciate and understand the "Get It Done" attitude, there has to
> be a better team approach to what is being done. Especially if Niels isn't
> always going to be available to fix problems. At the very least, I hope the
> changes are being properly documented.
Well, like I previously stated, there has nothing been done yet. I
merely provided the option to keep the status quo. It was an
interesting case study.
The funny thing is that I am completely susceptible to the presented
argumentation. I do understand that now that both webapps are hosted
on different servers, they are more susceptible to breakage. I also
understand that unixhead's reliability right now is unknown, and
therefore should be distrusted. The argument of extra load is less
prevalent, as it would only generate load when someone logs in.
I also agree that the inconvenience would not be for the 'user', since
they would register anyway. The only real inconvenience would be for
me (or us), when we have to manually generate accounts for all the
currently registered users :-).
So I'm in favor for dropping the current link, even though it is still possible.
N.
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
