- Development - lists.drupal.org

[drupal-devel] [task] quickie: The new default: break; case in updates.inc is unnecessary
by webchick 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31760 Post a follow up: http://drupal.org/project/comments/add/31760 Project: Drupal Version: cvs Component: database system Category: tasks Priority: normal Assigned to: Anonymous Reported by: webchick Updated by: webchick Status: patch (code needs review) Attachment: http://drupal.org/files/issues/updates.inc_5.patch (693 bytes) This is a patch that just removes the: default: break; case from both the documentation at the top and the most recent commit. Since there is no code to be executed on an "else" case, this code is unnecessary. webchick

1 0

[drupal-devel] upload module
by Bèr Kessels 20 Sep '05

20 Sep '05

Hello I decided to fork upload module, in an attempt to make it better usable, and change some other thingies. It is called betterupload, yet he filename remains upload.module My first landmark was to split it into upload.module and upload_display.module. The goal of this, is to make upload into an API-only module (i.e. a module that does nothing special really) for uploading files with nodes. No tables, file lists, inline images ad what more. Just uploads. With hooks and APIS, off course. upload_display takes care of displaying that table we have now. podcast.module could take care of nice podcasts. Inline_uploads.module can handle inline views, whatever_upload module can do the whatevers. My aim is to maintain this alongside (as much as possible) the core upload module. But to allow much faster and much more dynamic development. I feel core demands stability and security above all. But this very much limits the speed at which stuff can be developed for core. Basically anyone can contribute, as long as it remains within (usability) limits. So adding lets say, very pdf specific stuff in uploads, is not really an option. And of course this is a testcase to see if modules without those everlasting core discussions and -polictics ca deverlop themselves into better alternatives then core modules. I beleive this might very wel prove a nice workflow: let a feature prove itself core worthy by having it as contrib. Once its tweaked, revised, rewritten, again, and used by a lot of users, it can get into core. This tackles a few problems that I see in the current workflow: * Too much talk too much politics a lot of code, yet very little solid improvements. Our current system very much encourages tweaks, above solid rewrites. * Users (as in those USING) have no way to get involved in the development process. With this forking thing, they can influence, by merely using. Instead of only being able to rant about all hose new thingies in 4.7, once it is released. * Developers have a far quicker and looser way to get their code in. Uer feedback, developers feedback can then, later iron out the issues. (reverse reviews) * If such a project, finally makes it back into core, we can be sure it has passed the users test. Instead of merely passed four of five reviewers, it will pass both tests. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

1 0

[drupal-devel] [bug] Remove drupal module from core
by javanaut 20 Sep '05

20 Sep '05

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: javanaut Status: patch (code needs review) 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. javanaut 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.org drupal.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!

1 0

[drupal-devel] [bug] Remove drupal module from core
by nedjo 20 Sep '05

20 Sep '05

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: nedjo Status: patch (code needs review) 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! nedjo 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.org drupal.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.

1 0

[drupal-devel] [feature] Single step account creation and login
by thehunmonkgroup 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/4942 Post a follow up: http://drupal.org/project/comments/add/4942 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: amanuel Reported by: matt westgate Updated by: thehunmonkgroup Status: patch (code needs review) guys, jjeff and i are working on a custom login module ATM, which will live in contrib--and my plan was to integrate this patch as well as any other cool features related to login that we can think of. i think it would be a better approach to start this stuff out in contrib, and then move things to core if it makes sense. that will give us a chance to really polish things up, and only keep what's good. can we agree on that? thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Sat, 03 Jan 2004 23:49:54 +0000 : matt westgate Under special circumstances, i would like a new user to be able to choose their own password and be automatically logged into the site without needing to check their email. I feel this is necessary for my ecommerce module, where after anonymous users are ready to "Proceed to checkout", they need to create an user account to continue. It is tedious for the customer if they have to stop, check their email, log into the site and then resume the checkout process. I'm game to code this (if this has potential to be part of the core), i just need some feedback on the best way to tweak user_register. ------------------------------------------------------------------------ Sun, 04 Jan 2004 06:18:07 +0000 : moshe weitzman +1 for this. I don't think you will get much objection to this much needed usability enhancement. ------------------------------------------------------------------------ Thu, 08 Jan 2004 05:48:40 +0000 : matt westgate Attachment: http://drupal.org/files/issues/user.module-quick_acount.patch (7.11 KB) This is a prototype patch to make sure i'm going in the right direction. I feel this patch is about 95% complete, the outstanding issue being page redirection after quick-account creation. It introduces and new option under the user admin settings "Public registrations" called "Visitors can create accounts and sign in immediately.", allowing visitors to submit their own passwords upon account creation. This is important in an ecommerce site where a new customer wants to the checkout process to be as easy and seamless as possible. ------------------------------------------------------------------------ Thu, 08 Jan 2004 10:22:09 +0000 : moshe weitzman i read through the patch. looks good to me. a few notes - we should still send a password via email to users who choose their ow password. with some text tweaking, we should be able to send the same welcome email to 'generated password' registratants, and 'user specified password' registrants. - I think we need a setting for minimum length of a password. the password textfield should inform users of this requirement. - you don't actually relinquish control after saying "/* Let the developer control where the user is redirected. */". i assume this part isn't finished yet. nice work. ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:46:07 +0000 : flevour Are there any anti-bot checks around, e.g. randomly generated images that contain text or numbers to insert in a box? Congrats for your work :p // flevour ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:54:19 +0000 : Bèr Kessels I had another idea. that would be to filter all emailadresses (in content too) into a link to the feedback module. thus http://www.mysite.org/feedback/mailto/me/mysite.org the feedback can then print a form that can send the message to me(a)mysite.org. Would this be a good feature or not? Ber ------------------------------------------------------------------------ Thu, 08 Jan 2004 13:56:36 +0000 : Bèr Kessels sorry folks. placed this in the wrong box. Was updating another feature, and reading this one (to see if it was the same one) i then, by accident, filled replyed here. :( Ber ------------------------------------------------------------------------ Thu, 08 Jan 2004 16:49:56 +0000 : Dries Showing an image with random generated text that a user is supposed to copy, makes your website inaccessible for visually impaired: they can't be read by a screen reader. ------------------------------------------------------------------------ Thu, 08 Jan 2004 17:07:02 +0000 : matt westgate Responding to Moshe's comments: - we should still send a password via email to users who choose their own password. with some text tweaking, we should be able to send the same welcome email to 'generated password' registratants, and 'user specified password' registrants. That is a good point. I'll update the patch. - I think we need a setting for minimum length of a password. the password textfield should inform users of this requirement. Agreed. In my patch i checked to make sure the password was at least six characters long, but this should be an element that can be tweaked by the admin. It might be best to make this a global password length system variable. - you don't actually relinquish control after saying "/* Let the developer control where the user is redirected. */". i assume this part isn't finished yet. Yep, that's the part i'm still working on. Thanks for the critical eyes. ------------------------------------------------------------------------ Wed, 14 Jan 2004 04:31:06 +0000 : matt westgate Attachment: http://drupal.org/files/issues/user_0.module-quick_acount.patch (7.95 KB) The patch has been updated and is ready for final review, and commit. ------------------------------------------------------------------------ Wed, 14 Jan 2004 22:37:53 +0000 : Dries Not sure. Wouldn't it make more sense (and result in better/less code) to let the user *always* choose his password and to introduce a admin setting to control whether e-mail addresses should be validated by e-mail? ------------------------------------------------------------------------ Sun, 15 Feb 2004 17:02:38 +0000 : moshe weitzman moving out of patch queue until a cleaner implementation is submitted ... this feature is still quite valuable. ------------------------------------------------------------------------ Fri, 05 Nov 2004 19:21:49 +0000 : Nick Nassar I agree with Dries that it makes a lot of sense to always let the user choose her password. It's a pain to copy and paste in a randomly generated password, then change it. Hash link based verification is much easier. That's really a seperate issue from an option to disable verification. ------------------------------------------------------------------------ Fri, 22 Jul 2005 22:11:42 +0000 : amanuel Attachment: http://drupal.org/files/issues/user4.6.2.patch (4.25 KB) Following Dries's suggestion, I have implemented a "Enable Email Verification" option to user.module. The attached patch does the job. With this patch the system by default will ask for a password. If Email Verification is turned on in the settings, the system will send the password via email. $edit['destination'] is carried so as to allow the user to return where they were (shopping cart etc.) Any comments? Amanuel ------------------------------------------------------------------------ Sat, 23 Jul 2005 05:48:08 +0000 : matt westgate I want users to be able to enter their own passwords upon account creation, but this patch still needs some work. - The email verification checkbox in user admin settings is confusing. I'm assuming that it applies to any of the selected registration options? However when I select that only site admins can create new user accounts, the accounts I create don't get any emails sent for the user to verify. - When a user signs up and enters his/her own password I think they should be logged in automatically rather than taken to a screen asking them to click the login button. - User entered passwords aren't validated. We should check to make sure they're at least six characters and verify the password strength level to some degree (i.e. same characters, all lowercase letters.) ------------------------------------------------------------------------ Fri, 29 Jul 2005 05:09:30 +0000 : Steven I agree with Dries. Random-generated passwords are hard to use. We already have optional hash-link functionality on signup, so I think we should always use it. ------------------------------------------------------------------------ Sun, 07 Aug 2005 17:02:45 +0000 : killes(a)www.drop.org I actually disagree with Dries and Steven. I let firefox maintain all my passwords and couldn't care less what my actual pw for any Drupal based website is. If we let the user provide a password then I at least woudl want to havd Drupal suggest one for me. ------------------------------------------------------------------------ Mon, 19 Sep 2005 00:35:55 +0000 : Uwe Hermann I agree with killes here. Asking the user to choose a password usually results in _very_ insecure passwords. Give them random passwords per default in order to keep most of the accounts secure. If a user then changes the password to his pet's name, that's his problem... ------------------------------------------------------------------------ Mon, 19 Sep 2005 05:51:15 +0000 : robertDouglass I'd just like to mention that I recently needed a slightly different modification to the user creation workflow. The site was of the nature where all of the content was behind a splash screen that required registration before the visitors could get to it. My client needed his users to be taken to the content area immediately upon filling out the registration form and not have to wait for the mail and use their password etc to log in. I bring this up because there are probably 3-4 more workflows for account creation that we could support, if we wanted to, the current password creation issue being one of them. I would be supportive of adding more configuration options because I see that many sites have different needs. Options to add would include: 1) Should the user receive a generated password or should they get to choose their own? 2) If the user gets a generated password, it will be mailed; should they have to wait to log on, or should registering intitiate their session? 3) If the user chooses his or her own password, there is no way to confirm that they own the email address they entered. Should they be sent a 1-time URL confirmation mail and be required to click the link in order to confirm their mail? I would be very supportive of letting users create their own password if they were sent a 1-time URL to confirm their mail. How much interest is there for adding all of these options? -Robert ------------------------------------------------------------------------ Mon, 19 Sep 2005 06:35:20 +0000 : Crell The password should always be emailed to the user. They will forget their information otherwise. :-) I too would like to have the option of email-less account creation. I just finished part 1 of a project for a client where we're using Drupal more as an app framework for an intranet app than as a CMS. Avoiding the "now check your email" step was a mandatory requirement of the system, so I ended up hacking user.module to give all users the same auto-generated login button that the first user gets. For an intranet application (or pseudo-intranet in this case, silly as it is), that's acceptable. For a public site, that is begging for spambots. Even with CAPTCHAs or similar verification techniques, it opens the site up to spam. However, if a site doesn't have user-generated content but does have a need for registration (ecommerce, for instance), skipping that email step is also very important. An email should still be sent, as I said, but you're going to lose your customers if they have to go to their email twice (once to create an account, once to get their receipt). Perhaps an admin option to allow users to log in immediately upon account creation, defaulting to no, with a big message pointing out to the admin that it's a potential security hole if the "registered users" role has any content-creation capability at all. That would be an entirely different question from letting users enter their own password. Given how easy it is to get a new password in Drupal already, I'd say we should still just auto-generate in all cases. They can change it if they want. ------------------------------------------------------------------------ Mon, 19 Sep 2005 08:18:56 +0000 : Kobus I believe that a one-time url is a good solution, and that it is a MUST add if you add the "own password" option. If you generate the password, just add the "log in" button and redirect to the page the user requested/requires. Mozilla 1.7 has a password security meter built in. If you allow users to generate their own password, couldn't something like this be implemented with AJAX (which, of course, is unavailable if degraded?) Regards, Kobus ------------------------------------------------------------------------ Mon, 19 Sep 2005 14:49:20 +0000 : moshe weitzman Robert - your proposed preferences for user registration look great to me. I encourage you and others to pursue this direction.

1 0

[drupal-devel] [bug] Remove drupal module from core
by Peter Apockotos 20 Sep '05

20 Sep '05

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: Peter Apockotos Status: patch (code needs review) 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. Peter Apockotos 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.org drupal.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.

1 0

[drupal-devel] [feature] Separate mail backend
by killes 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/28604 Post a follow up: http://drupal.org/project/comments/add/28604 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: Dries Updated by: killes(a)www.drop.org Status: patch (code needs review) @vwx: How did you send the mails? direcly or through the queue? can you try to queue the messages and use the throttle setting? Also, I believe we do neeed aid. There might be the same address twice in the same batch of mails. How the code should be split up depends on Dries, I guess. Personally I'd put the module functions into system.module and the rest into a small .inc that is lazily loaded like the .incs for xmlrpc. I don't think we need a way to look at the queue in core. Do you eve look at sendmail's mailqueue? I don't. @noid: this issue is not about simplenews, but we do have a throttle setting. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 12:35:37 +0000 : Dries It was suggested that we separate the mail backend from the front-end. We might want to include the mail backend in core as includes/mail.inc. Then, other modules like massmailer, subscriptions, notify, pm (private messages), project (project issues), contact, etc. could reuse this component. The mail.inc file would implement some kind of mail queue functionality, and modules just add a mail to the mail queue using a simple /mail API/. In future, the mail backend could deal with bounces and report back proper status codes. Moreover, mail.inc would be pluggable so it could be replaced by a more powerful one, or one that is build specifically for the underlying mail transport (SMTP server). Furthermore, this would solve issues with how many mails get send within a specified interval. Like, when more than one module sends out e-mails it is hard to enforce limitations/restrictions imposed by the hosting company. I'm posting this here so you can keep this in mind when working on simplenews, and to solicit for feedback. Chances are we'll setup an IRC meeting to discuss this further. Details to follow. ------------------------------------------------------------------------ Wed, 10 Aug 2005 16:15:16 +0000 : Amazon A good place to start would be to look at existing Mail API's Pear Mail: http://pear.php.net/package/Mail Pear Mail tutorial: http://www.zend.com/pear/tutorials/Mail.php#Heading2 ------------------------------------------------------------------------ Wed, 10 Aug 2005 20:21:57 +0000 : walkah um. +1 and then some. I think this is good... and some good references from Amazon. I'll throw in one other : http://phpmailer.sf.net/ - has great mime handling (i've run into issues with PEAR::Mail's mime handilng in the past, but that was around 2 years ago, and things may have gotten better since then). Oh - and you don't mention it - but support for multipart / mime messages would be lovely :) I'd be interested in / happy to sit in on any IRC discussion as well. ------------------------------------------------------------------------ Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass phpmailer++ I've used it and like how easy it is to send both text and html mail. Did I say html mail? You bet! It's time that we had the option. ------------------------------------------------------------------------ Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx I'm definitely interested. Hopefully by adding a post to this I'll get notified on new postings (?) If not I may miss the IRC .. I've been doing a lot of work with safe_mode PHPLIST (have posted to the drupal site somewhee, can dig out the reference if anyone is interested). Charlie in TX ------------------------------------------------------------------------ Wed, 17 Aug 2005 08:42:34 +0000 : Dries It was suggested that mail.inc also provides a HTML to text services. Lots of modules (newsletter, notify, project) try converting HTML to text. Having a reusable function makes sense, and will lead to better conversion routines. XSLT anyone? ------------------------------------------------------------------------ Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2 +1 for phpmailer I found it very easy to use - and most importantly for me - it supports SMTP authentication. As many ISP's will not let you send mail without using SMTP-auth nowadays it may be worth this feature is incorporated into the mail.inc API. - Grug ------------------------------------------------------------------------ Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo For about a year now I've been working on an email newsletter and announcement module [1]. There's a version in my sandbox commited about 2 months ago which works fairly well. Dan Robinson and Varr Willis at CivicActions, Moshe Weitzman plus a few others have been testing it, and I've had lots of positive feedback and feature and bug reports from them. A few months ago a realised that there's not much point in putting so much effort into creating all this functionality, only for it to be locked away in my module. Better to Better to create discreet component modules which provide a particular service, such as bounced email handling, but which can be used by any other module that also needs that service. For the last two months I've been working to split functionality into component services modules and make these services available to all modules. One of the biggest challenges was to make these component modules independent of each other. The only area where I haven't managed this is some of the database calls - but thanks to a chat with chx I realised that db_rewrite_sql could be used to handle this very nicely. This is what I have: * bounced_email.module - process bounced emails * html2text.module - convert HTML to plain text equivalent (e.g. list item becomes "* item") * identity_hash.module - manages full and partial loggin based on hash which can be used in email links * publication.module - defines and packages content of publication, which could be any kind of publication * schedule.module - defines and manages schedules, e.g. email sending schedule * subscribed.module - manages subscriptions to publications * templates.module - manage and define templates What's great is that the component modules are not limited to email, they could be used to quickly create RSS newsletters, PDF newsletters, text message newsletters, or even personalised/filtered website sections. I haven't made the new component modules available anywhere yet, but I'll be happy to upload them to contrib and let others get involved. What would be the best way to commit them - as a single directory? or each component module in it's own directory? [1] http://www.cortextcommunications.com/development/newsletter/features ------------------------------------------------------------------------ Thu, 15 Sep 2005 02:05:18 +0000 : vwX Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB) This is a very basic mail queue system I would like to contribute. There are some changes to other modules that will have to be made such as changing user.module to use this instead of directly calling the php mail function and moving mime_header_encoding to mail.inc. ------------------------------------------------------------------------ Thu, 15 Sep 2005 15:25:11 +0000 : killes(a)www.drop.org Note: I am moving this to the main project. VwX: What I see looks very nice for a start. Some polishing is certainly needed, but I'd like to try this. If I only had the time... ------------------------------------------------------------------------ Fri, 16 Sep 2005 22:10:19 +0000 : killes(a)www.drop.org Ok, I've been doing some clean-up on this one and made contact.module use it. The module and the .inc file work. I've put the files into my sandbox for now. I plan to work on them over the weekend (unless Dries tells me they are too late for 4.7). http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/ But I could use some input: - the sql file defines a column to store the module that generated the mail. Do we want this? If yes, we need to fix it. - Do we need a throttle for only sending x mails per cron run? - can somebody try the files with php5? - what else do we need? Please give input, links and what not. ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:34:04 +0000 : Dries Some of my comments might be false. If so, sorry. I only looked at it for 5 minutes: * I wonder why we need per-module settings. I can't think of concrete use cases. * For consistency, mailid needs to be mid. * I don't see an option to send mails immediately? * I don't see any "messages per hour" accounting? * I don't understand why mail.inc should be node system aware? * mailid = '%s' should be mailid = %d. * Incorrect use of t(): don't translate user input. * The coding style needs work; inconsistent variable names, inconsistent spacing, etc. * Some PHPDoc is rather cryptic: /Updates table mail queue address table sets sent flag to 1 for a queued msg./. ------------------------------------------------------------------------ Sun, 18 Sep 2005 04:28:11 +0000 : killes(a)www.drop.org I've fixed a number of things. needs testing. ------------------------------------------------------------------------ Mon, 19 Sep 2005 02:28:25 +0000 : killes(a)www.drop.org Ok, changed and tested. Some more changes, taken some concepts from massmailer.module. Included hacked copies of simplenews and contact module for testing purposes. We need to discuss if this should be a module or a part od system.module. depending on the outcome we need to put the functions in mail.module and mail.inc into different files. Testers welcome. ------------------------------------------------------------------------ Mon, 19 Sep 2005 06:31:04 +0000 : Peter Apockotos Dries, Are you talking about something like I request here http://drupal.org/node/28079 ? ------------------------------------------------------------------------ Mon, 19 Sep 2005 18:15:20 +0000 : m3avrck Well first off, just wanted to say I'm currently evaluating this and been sending regular feedback to killes for improvements. So far so good on PHP5 machines :-) But in terms of where should this code go, I think mail.module should be eliminated and those functions should be put in mail.inc which *should* be seperate from common.inc. This way, as Drupal grows and more and more modules depend upon mail functions, they will be in their unqiue spot which can easily be patched and extended instead of rummaging through the common.inc mess ;-) As a result, the mail.module settings should be moved to Admin > Settings with the mail setup there, since the basic Drupal "request new password" etc framework requires mail functionality and having these settings there makes the most sense, usability wise. I think with this setup the code could be organized in the cleanest and most straightforward method and would be an elegant refinement in mail handling for 4.7... no new features, just cleaned up and seperate for other modules to make use of, instead of duplicating code and time. This also has the benefit of bringing in more patches to the Drupal core and how it handles mail and making it rock solid. Just my 2 cents. ------------------------------------------------------------------------ Tue, 20 Sep 2005 03:14:25 +0000 : vwX Did some testing on Killes changes. Queued ~1000 addresses for one email. When sending started receiving this message : " warning: mail(): Could not execute mail delivery program '/usr/sbin/sendmail -t -i ' in /home/webuser/mars/www/drupal/modules/mail.module on line 189. " at around message 258. Looking further seems sendmail got hammered. This is a RH6.2 box 550MHz processor with 256MB memory and sendmail configured to use a smarthost qmail server. I can share the script to test if anybody wants to help. Will try a bit more after I do some tuning. Now about the changes. I think that the mail_queue_addresses table key structure needs to be changed. Remove Aid and just use address. Also, I've always used a primary key structure of parent table primary key + one or more additional keys for a child table. Originally I had something like this, but it is now one primary key and an index. I don't think this is correct and I've been doing database work for 15 odd years. Also, I agree with what m3avrck says. Orginally when I submitted the code I had most of the functionality in mail.inc and the module was primarily for administrative functions. I also functionality to view what was in the queue and force the sending of messages in the queue. That has since been removed and I think it should be re-added. ------------------------------------------------------------------------ Tue, 20 Sep 2005 11:39:42 +0000 : noid Sorry guys for interrupting your discussion, but just wanted to make sure that batch processing ( that is, to help guys like me whose host limits the sending of emails to say, 200 per hour) is still not implemented in Simplenews? From my shallow understanding this is what you are working on right now? Raised this issue which Dries marked as duplicate here: http://drupal.org/node/28311 . Just wanted to make sure that I didn't miss the release of this feature. Thanks in advance! :)

1 0

[drupal-devel] [bug] Remove drupal module from core
by Prometheus6 20 Sep '05

20 Sep '05

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) 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. 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.org drupal.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.

1 0

[drupal-devel] [bug] Remove drupal module from core
by killes 20 Sep '05

20 Sep '05

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: killes(a)www.drop.org Status: patch (code needs review) 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. killes(a)www.drop.org 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.org drupal.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.

1 0

[drupal-devel] [bug] Remove drupal module from core
by Bèr Kessels 20 Sep '05

20 Sep '05

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: Bèr Kessels Status: patch (code needs review) 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.org drupal.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. Bèr Kessels 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

1 0