Ber,
This does sound interesting. It has its perks and its downfalls, but all in all, it will remove clutter from the site for non-admin users. However - what would happen if you have more than one admin in different levels (or roles)?
My point here being - rather than make a "admin" role, rather make a "user" role. But this is already accomplished. By assigning proper rights to your users, this would be a non-issue, or am I misunderstanding your request?
Regards,
Kobus
>>> berdrupal(a)tiscali.be 9/21/2005 8:46 PM >>>
Something I always liked to know is:
Do you ever (want to) administer drupal with your default login. (i.e. how
many people have a separate account to administer)
I think an well founded answer to that will make our future choices a lot
easier: Does the admin menu need to be part of navigation menu, How well
would an admin theme help (for the record, i think admin themes are not a
good idea), would a default administer role help etc.
Ber
Op woensdag 21 september 2005 19:45, schreef Kieran Lal:
> On Sep 19, 2005, at 10:28 AM, Kieran Lal wrote:
> > On Sep 19, 2005, at 9:45 AM, Álvaro Ortiz wrote:
> >> So if some concise usability/ux improvements were listed, I would
> >> contribute.
> >
> > Here is a list projects for Administration User Experience that we
> > need help with.
> > 1) We need to complete interviews for new administrative users. I
> > have completed 12 so far, but they were all with heavy
> > administration users.
>
> Hi, here is the short version of the interview questions:
> Audience research
> Phone/email interview questions
> Drupal administration
> 1)How would you describe yourself as a Drupal administrator? Which
> version of Drupal
> do you run? What additional modules/themes do you use?
> 2) How often do you use Drupal administration? How long do you
> administer your site?
> 3) Can you access your Drupal administration menus?
> 4) What are the most common tasks you do with your site as an
> administrator? What
> other tasks do you do less frequently?(Write both answers down as a
> list in order)
> 5) Which of the common tasks you mentioned earlier are easy to do?
> Why are they easy?
> (Get into detail)
> 6) Which tasks are hard? Why are those tasks hard?(Go into detail)
> 7) How about other important tasks you have not mentioned?
> 8) What is the one thing that would make your job as a Drupal
> administrator easier?
> Review your interpretations.
>
> If you would prefer to just do one or two long interviews then I can
> share the long interview questions which really follow the same
> format but have lots of detailed sub questions. When you are picking
> your candidates to interview check that they don't use Drupal
> administration for an hour everyday. I have twelve of those people
> and we really need a better sampling of new inexperienced users.
>
> I am going to try and get a post up on Drupal.org about a plan for 4
> weeks of User Experience work.
>
> Cheers,
> Kieran
Bèr
--
[ Bèr Kessels | Drupal services www.webschuur.com ]
Hello world,
we approved a number of new CVS accounts. Please welcome our new
contributors, and assist them as necessary.
--
Dries Buytaert :: http://www.buytaert.net/
I'm not quite sure what you're after here but you should be able to
install flexinode and create your own content type called "foo" and
then "allow signups" for this type.
I created a "training event" and "corporate event" flexinode type for
this very purpose.
Perhaps if you could better describe what you're trying to do, big
picture wise, we could help. I'm becoming quite familiar with the
signup module (I've made quite a few mods and fixed some bugs; just
need to get some time to do a diff and create a patch) so I could
probably help you out here.
On 9/21/05, mdowsett <thehunmonkgroup(a)yahoo.com> wrote:
> Issue status update for
> http://drupal.org/node/31586
> Post a follow up:
> http://drupal.org/project/comments/add/31586
>
> Project: Signup
> Version: 4.6.0
> Component: User interface
> Category: feature requests
> Priority: normal
> Assigned to: mdowsett
> Reported by: mdowsett
> Updated by: mdowsett
> -Status: by design
> +Status: active
>
> Sorry to bug you again. All nodes that I create have sign in boxes. I
> don't want that but I see no way to turn it off of certain types of
> nodes.
>
>
> I wish there was still an "Event" node under Create Content and that
> was the only node you could put signups (and RSVPs for that matter).
>
>
> And would you know where I could put a request in for an entire new
> module (kind of related to events).
>
>
> Thx
>
>
>
>
> mdowsett
>
>
>
> Previous comments:
> ------------------------------------------------------------------------
>
> Mon, 19 Sep 2005 00:57:27 +0000 : mdowsett
>
> Can you rig it so that if you are a signed in registered user, you can
> simply check a box that says sign me up for a certain event rather than
> having to fill out name, phone number and email?
>
>
>
>
> ------------------------------------------------------------------------
>
> Mon, 19 Sep 2005 01:34:48 +0000 : thehunmonkgroup
>
> the signup form is not necessary for event signup, by design. the form
> itself is totally themable, and can be eliminated entirely--the code
> should work fine w/ no form at all. just head in to signup.theme, and
> comment out the form elements (leave the function and the return
> statement). that should eliminate the form and just leave the signup
> button. if that doesn't work, let me know and i'll look into it...
>
>
>
>
> ------------------------------------------------------------------------
>
> Mon, 19 Sep 2005 23:49:37 +0000 : mdowsett
>
> Thanks! I do follow what you are saying (in theory). I tried just
> clicking the submit button without filling out the form and it does
> work slick. It may be worth it to put in your default module a text
> line that says something like "Fill out the form below OR just hit
> Submit and your user info will be "Signed Up".
>
>
> I am not a coder so I am pretty reluctant to adjust code. But willing
> to give it a shot!
>
>
> I found this section of the module which I think is the section you are
> talking about:
>
>
> //user isn't signed up, so check to make sure they have signup
> //permissions. if this is the case, then print the themed
> signup form
> if (user_access('allow signups')) {
> $form_data = theme('signup_user_form') . $hidden .
> form_submit(t('Click Here to Sign up now'));
> $form = form($form_data, 'post', url('signup',
> drupal_get_destination()));
> $output = form_group(t('Sign up for %title',
> array('%title'=>$node->title)), $form);
>
>
> I adjusted the text of the submit button so I think I am in the right
> place but I can't figure out how to delete the fields.
>
>
> Would you mind giving me some replacment lines of code to help me out?
>
>
> Many thanks,
> Mark
>
>
>
>
> ------------------------------------------------------------------------
>
> Tue, 20 Sep 2005 00:44:30 +0000 : mdowsett
>
> I fixed it myself...
>
>
> I was looking at the .module, not the .theme.
>
>
> Works like a charm now!
> Thanks for the tip.
>
>
>
>
>
Hi,
Last fall, Walkah announced an S5 module in the works
(http://bryght.com/node/121) which was a proof of concept, but was
never actually released as far as I know. I was way too excited about
the possibilities, and given that my repeated requests resulted in no
code from Walkah (due to the apparent reason of not enough time), I sat
down this weekend, and put together a simple module for S5 authoring
with the book module. The module is now in Drupal CVS
(http://drupal.org/cvs?commit=19502)
I know reusing books is still not the ideal solution for slide
authoring, but since only book has an outline editor in Drupal, it was
the quickest to use, and I am going to have a presentation on Drupal
this weekend, so I only had this much time. I have ideas for futher
improvements (actually either creating a better outline editor for
books, or abandoning books).
Here is the README reproduced for those interested:
S5 Presentation Module Suite
----------------------------
The modules in this suite are supposed to help you author and play
S5 presentations. S5 is Eric Meyer's "Simple Standards-Based Slide
Show System", which is based on the Opera Show format. S5
presentations work in a multitude of browsers, and also compatible
with Opera Show.
http://www.meyerweb.com/eric/tools/s5/
Installation requirements
-------------------------
- Modules in this folder are compatible with Drupal 4.7
- S5 itself is not included. You are required to copy the
contents of the 'ui' folder from your S5 download to misc/s5.
That means you should have files like misc/s5/default/slides.js
The s5_book module
------------------
This module allows you to play book pages as S5 presentations.
Enabling this module, you will get an 'S5 Presentation' link
by the side of your 'docbook export' and 'opml export' links
on your book pages. This flattens your book structure, so any
hierarchies will be lost. You can use hierarchies however to
structure your presentation properly. Since books only allow
you to distinguish 30 different page weights, if you have
more slides, you need to use hierarchies to maintain proper
ordering. Group your slides by topic, and give your topics
starter slides.
The first slide is searched for metainformation about your
slides, which is injected to further slides. An example first
slide is the following:
<h3 class="s5-author">Name of Author</h3>
<h4 class="s5-company">Company of Author</h4>
<!--p class="s5-presdate">Presentation date</p>
<p class="s5-location">Place, Date and time</p-->
As this example shows, you will have your name and company
displayed on the slide (the slide and thus the presentation
title will be the first node title). Since the presentation
date and location information is in HTML comments, it will
not be displayed. The s5-presdate value is supposed to be
something like 20050920. For more detailed information on
how these values should look like, look into the S5
documentation.
Other slides should contain HTML like:
<ul>
<li>point one</li>
<li>point two</li>
<li>point three</li>
</ul>
See the S5 documentation on what else you can use on the
slides, like handout text, images, incremental display, etc.
Practical usage
---------------
Authoring presentations with the book module might not be
the ideal solution, since it does not allow you to easily
add and remove slides. For this reason, s5_book module
adds an 'add book page' link to the book outline editor
(look into administer >> content >> books). This way,
the outline editor allows you to quickly view, add and
remove slides, as well as reorder them.
Possible later modules
----------------------
Since authoring slides with the book module is still not the
ideal way to look at slideshow editing, there are ideas on
the future direction of supporting S5 authoring. When or
whether these will be implemented at all is still an open
question. Contact the maintainer, if you would like to join
forces.
Credits
-------
Thanks to Eric Meyer for this fantastic slideshow system.
The s5_book module and this readme was written by Gabor Hojtsy
<goba(a)php.net>.
Hello world,
- Thanks to Corey Shields (OSL) and Matt Rae (OSL), the two remaining
Dell 1850's are in place; they are called 'drupal2' and 'drupal3'
respectively, and are humming along in OSL's server room. We're
already using 'drupal1' and 'drupaldb' (aka Sun-prise).
- drupal2 will act as a second web node along side drupal1, the
current web node. drupal2 will be put in production shortly. At
that point, drupal1 will go down for a while as they have to rebuild
the machine. We need to enable NFS, LDAP, and rebuild some stuff in
32-mode because some stuff doesn't behave in 64-bit mode. We won't
be running with two front-end web nodes for another week or so.
- OSL has put a gigabit switch for private networks in the same rack
our servers are in. The second network interface will be plugged
into the gigabit switch so we'll have a very fast private network
between all of our machines. Given we're going to run stuff over
NFS, this will be good. From a security point of view this is great
too; as all data communication remains on our private network.
- drupal3 is up and running and has all the software installed to
host our mailing lists and CVS repositories. Credits go to Matt for
installing everything. Next up, is migrating the mailing lists and
CVS repositories from the old drupal.org server to the new drupal.org
infrastructure. Kjartan is going to work on this in the near future.
So far the status update.
--
Dries Buytaert :: http://www.buytaert.net/
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: robertDouglass
Status: patch (code needs review)
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
Another example:
http://kerneltrap.org/user/2524
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
attractive idea.
PLEASE TELL ME I'M WRONG! Or remove the module.
robertDouglass
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
Is anyone getting this? Sorry for the spam but I'm getting "Your
message to Infrastructure awaits moderator approval" due to a
"suspicious header" for every message I send.
a) not sure why my header is "suspicious"
b) I'm not even signed up for the Infrastructure mailing list.
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: Prometheus6
Status: patch (code needs review)
Hm. Pubcookie requires SSL and (possibly worse) accurate system time.
http://www.pubcookie.org/docs/install-mod_pubcookie.html#req
Prometheus6
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
Another example:
http://kerneltrap.org/user/2524
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
attractive idea.
PLEASE TELL ME I'M WRONG! Or remove the module.
------------------------------------------------------------------------
Tue, 20 Sep 2005 11:17:00 +0000 : eldarin
Robert, you make perfect sense.
;-)
Other servers could get compromised like you point out, and that could
let someone take control of drupal.org if a siteadmin used the
compromised site with the same account login. This could especially be
true if a site used an earlier Drupal version. And it's not only
current sites using this, but future sites and possible future modules
which can be used to compromise security. Someone could offer
my-cool-module.module and distribute it through some other forums,
thereby getting some backdoor access. Using the distributed login
feature, they could behave like a worm.
Ultimately, it's up to the users to show good thinking and NOT use the
same username or password everywhere .. but that is difficult to
demand. Scenario example: two websites have siteadmins which know each
other well (or same person), and same person registers on both sites.
If the password is very similar or a pattern can be discerned and if
that person is a drupal.org siteadmin, the possibility exists that
drupal.org still could get compromised.
There is no way to be foolproof, but helping users along doesn't hurt.
;-)
------------------------------------------------------------------------
Tue, 20 Sep 2005 11:34:07 +0000 : chx
I agree.
I have looked around for better solutions and pubcookies looks good.
(Google on it. I do not have too much too time to write about it.)
------------------------------------------------------------------------
Tue, 20 Sep 2005 13:53:36 +0000 : gravyface
Of course, this assumes that Gerhard uses a different username and
password combination for every site, which most people don't; if not,
you wouldn't need to exploit the distributed authentication to get this
to work -- you could take the average user's account and not only log
into other Drupal sites but into Hotmail, gmail, Paypal, eBay, etc.
I agree with Robert; I think that this should be removed from the core.
Single Sign-on (SSO) [1] is not an easy thing to tackle and outside of
a controlled, private network, it may not even be desired. Look at
Microsoft's Passport failure [2] as an example; the largest software
company in the world could not get this to work and apparently, nobody
wanted it either.
[1] http://en.wikipedia.org/wiki/Single_sign_on
[2]
http://yro.slashdot.org/article.pl?sid=04/12/31/1416212&tid=109&tid=158&tid…
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:04:36 +0000 : kbahey
For me, I never liked distributed authentication, be it from Microsoft
Passport or from Drupal or anyone else.
The point here is that you are trusting others to do security for you.
Those others can be malicious, or can be slack in their security, or
they got get hacked by someone else.
So, for me, this is something that I will likely never use, whether it
stays in core or not.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:10:13 +0000 : m3avrck
I agree with all said points. I never had used drupal.module and never
plan to. Great idea in concept, but in reality, just doesn't work.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:15:45 +0000 : Kobus
I agree with the posts before, but will this influence the drupal-sites
functionality? I have a few old Drupal 4.2 sites utilizing this feature
to list themselves on the drupal-sites page.
Regards,
Kobus
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:30:37 +0000 : Bèr Kessels
1Though potetially insecure, iSSO is one of the best features in drupal.
I'd rather notsee this end in the null bin, for it will then be lost.
forever. What about a revive/rewrite?
Here are my thoughts: case: drop.org user 'foo' log into Drupal
drupal.org pings drop.org. Drop.org retruns TRUE if the pinged details
are correct.
foo(a)drop.org is NOT a user nor gets a uid on drupal.org. never! For as
long as the session takes, he is a 'registered' user.
if foo(a)drop.org visits 'my account' and changes anything in there, he
gets a uid, welcome mail and a native drupal.org user. That has, from
then on, nothing to do with drop.org, drop.org will never be pinged
anymore. Off course one is required to fill in a new password and an
email addy.
if foo(a)drop.org never visits 'my account', or does not change anything
in there, the user 'foo(a)drop.org' will be lost as soon as the session
terminates.
drupal.org user with a lot of rights 'foo' logs into drop.orgdrupal.org will send TRUE when it receives correct login details.
foo(a)drupal.org is NOT a user nor gets a uid on drop.org. never! For as
long as the session takes, he is a 'registered' user. but drop.org
knows nothing, nor saves anything on drop.org. only packet sniffers can
track the user details;
This is very much how it works now, with one difference: you have to
actively undertake something to me changed from remote user to native
user. You have to actively undertake something to get yuour details in
the database of the other site.
This, Icw some common sense (Dries should be aware that he must not use
his drupalID on WannaHackdrupal.pr0nnet.ro) thiswill do, IMO.
First rule of securit is clarity:
if your users see and feel what happens, your security is much better
maintainable. This is not really the case ATM.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:31:40 +0000 : killes(a)www.drop.org
I am using my username only for historical reasons. drop.org is down and
I've not been using distributed auth for quite a while. I agree that
drupal.module's distributed auth isn't up to date any more and people
shoudl be discouraged from using it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:55:44 +0000 : Prometheus6
The module would be useful if the side that does the authentication had
a list of trusted sites. That would let you have single sign-on across
a range of related sites. But that still means it's more appropriately
a contribution module.
------------------------------------------------------------------------
Tue, 20 Sep 2005 15:52:16 +0000 : Peter Apockotos
I like the idea of the module.
I just wish it wasn't tied to drupal.org itself.
Perhaps a setting of which (trusted) sites to share the information
with instead.
------------------------------------------------------------------------
Tue, 20 Sep 2005 16:20:59 +0000 : nedjo
Thanks for bringing this issue up, Robert. See for reference the
related issue "Refactor and rename drupal module",
http://drupal.org/node/29826
The near consensus I'm hearing is:
1. The functionality areas covered in the drupal.module are valuable
and desired.
2. But the current implementation has serious flaws, and therefore
fails to meet clearly the standards for drupal core inclusion.
There are probably three basic options:
1. Keep the module in core, with the commitment to fixing its flaws.
2. Temporarily (e.g,. for one release cycle) pull the module from core
with the aim of refining it enough for reinclusion.
3. Remove the module from core to contributions.
While I agree with the serious limitations of the current
implementation, I'd hate to see this functionality area disappear from
core. Projects pulled from core tend to languish. So I favour
options one or - perhaps better - two.
Inter-site functionality similar to what is covered in drupal.module is
in increasing demand. Projects like the telecentre.org initiative
centre on such functionality. CivicSpace has expressed keen interest
in improving the ability of webs of related sites to discover each
other, connect, and pool information. Look again at our mission,
http://drupal.org/node/10250. Inter-site connections are increasingly
key to "the collaborative production of online information systems and
communities".
Let's focus on fixing the module!
------------------------------------------------------------------------
Tue, 20 Sep 2005 17:28:34 +0000 : javanaut
Just contributing some links to the discussion here.
There was previous discussion on distributed auth here:
http://drupal.org/node/19113
Parts of this discussion fed what became OpenID: http://openid.net/
There's a PHP implementation of OpenID here (I've never used this,
though): http://www.videntity.org/openid
If somebody had time/motivation to develop an auth module that used
this, I think it would bode well for Drupal, whether core or contrib.
It's primary benefit is that you need not trust the site that you're
logging in to, just your main server. You never enter your password
into a non-trusted site.
------------------------------------------------------------------------
Tue, 20 Sep 2005 19:23:47 +0000 : Boris Mann
Both CivicSpace (Kieran, I think we agreed on this) and Bryght are
commited to developing distributed authentication functionality.
We would love if something shipped by default with Drupal core.
OpenID is my current best bet, although as chx pointed out, Pubcookie
looks excellent for the more corporate market.
My proposal would be to make drupal auth an OpenID compliant server,
and to make the "base" dist auth have the proper trust
relationships/security that people could be confident in using it in
most standard security situations.
The current "drupal" module would actually become more of a container
for dist auth in general, as it has been in the past. One of it's
functions might be (for example) mapping remote information to local,
as we implemented for the SXIP module.
Issue status update for
http://drupal.org/node/2694
Post a follow up:
http://drupal.org/project/comments/add/2694
Project: Drupal
-Version: <none>
+Version: 4.6.3
Component: profile.module
Category: feature requests
Priority: minor
Assigned to: Anonymous
Reported by: Anonymous
Updated by: Peter Apockotos
Status: fixed
I have these fields setup in my profile fields. but is there a way to
code the fields so that when clicked on it will launch the clients IM
client to contact that user?
Peter Apockotos
Previous comments:
------------------------------------------------------------------------
Sun, 31 Aug 2003 09:17:01 +0000 : Anonymous
It could be great that in profile you could specify your Jabber ID (as
you can specify your ICQ, MSN, Yahoo or AIM messenger ID).
Thanks.
------------------------------------------------------------------------
Wed, 27 Jul 2005 04:36:40 +0000 : Eric Scouten
Fixed long ago. Current profile module allows admin-defined additional
fields.
