email address not required on user edit page

As far as I know this is standard behaviour. The functionality lets you authenticate with an ID from another site but no other information is passed along.

yeah

Maybe the whole user page should be disabled when you login from another site, without losing any of the standard functionality and without sharing any more information that is needed between sites. e.g. The remote site should be able to determine if your contact form is set and when you send a contact email it should send it to the original site which forwards it to the email you have registered with. (Is some XMPP subset a possiblity?). Then you could even create a "Who's new globally" block on Drupal (or something)!

I think there is indeed room for some improvements.... let me think this through....

I maintain a cas single sign on module.

I think it's true that many drupal implementations might not require an email in order to function. I can think of just as many that may want to require this. Perhaps the best approach would be to add some user account/policy setting to control whether this is required, in the same form that controls whether user registrations are allowed, and whether remote drupal auth is enabled?

There are other policy items on my own single sign on integration wish list. Ideally I'd like to be able to control whether users see the password reset fields on the user edit screen as well, since with many SSO solutions it doesn't actually do anything.

I would argue against disabling the user screen(s) because of all of the "hook" functionality that this would also disable (theme preferences, block preferences,etc).

This does seem like it should be a site admin policy decision. Drupal does not require an email address to function correctly. So whether an email address (which Drupal forces to be unique among all users -- yet another policy question) is required or not should be up to the site admin.

i agree - admin preference sounds good. but does the pref only affect the edit page? what about normal registration? maybe this is a job for a contrib module. is easily dealth with via form alter.

I suppose it could be done with a contrib module, but using the alter_form hook to remove validation that's in core kind of creeps me out. Didn't I hear someone on the dev list suggest that might be stupidity?

Given the utility to the core drupal distributed auth functionality it seems like it might fit. Would such a patch not be welcome in core?

I'm willing to give rolling one a shot if there's core developer buy-in.

Dave

Ok in the spirit of trying things that make me uncomfortable, I decided to give this one a shot. It worked for my password issue, but not for the email validation issues. The user module does not honor the #required attribute in the form due to the email validation logic. It looks like you can't achieve the desired behaviour without hacking user.module.

If you aren't convinced, try commenting out the default value setting logic in this code and try it for yourself.

What you can do, however is default in an email address. I wrote this policy module as an example, but I think I'll roll the functionality that I need into my CAS module instead. It won't help yogadex, but perhaps it will perhaps bolster the case for a user.module patch of somekind to address the problem described.

I have read the issue, but first I'm not a PHP programmer. If I have understud everything exactly I thing that
if you add (whatever it is) a kind of default role like "TESTUSER" that is installed by default as "ANONIMOUS"-User and "AUTHORISED"-User you may decide that for the "TESTUSER" is not required an email authentification or whatsoever.
Hope I did not talk "B........t" Bye

@Jax (#4) Does the remote site also notify my site if the user's account is blocked or deleted? If not, then I need contact information locally.

@NancyDru Suppose there's no need to notify because every time user loggin in module contact remote server and check (username, password, status=1)

But email address is really a problem...

Guys,

there are some ways to face the problem:

1* Share all data: it means that, once ia new user logs using the distributed auth, the server site send all info about the user. It is VERY risk (since it breaks the disclore agreements and can share sensitive data). But it might be impolrtant for sites fro mthe same owner, like drupal.org and groups.drupal.org

2* Share no data: if no data is given from the server, it makes sense to block the user page from the "my account". At least the sensitive part as email, username and password.

3* Share predifined data: like OpenID, sites that server should ask users what kind of information it might give to other sites.

As you can see, the current way is number 2 and its the worst case. We need to think on changing it.

its important to say that since the password is typed on the client site, it can be easily recorded. security is currently null.

regards,

massa

As I know d.o is going to 6юч branch so what is the future of drupal.module in upgrade context? Maybe move this discussion to "Drupal.org architecture" project? By this way we can draw attention to the problem! There should be a migration proposal and gateway maybe from drupal.login to openid!

Andrey,

i cannot agree less.

regards,

massa

Subscribing.

Guys,

sharing data can be done thru Web Services module. There is no reason for duplicating the feature.

#18: Link does not work, do you mean your newly published module information here:
http://drupal.org/project/webservices

It does not have any releases yet, so it does not pose a solution as of now.

Let this discussion live a little longer until we have reached a conclusion.

Webservices today is 6.02 release - so is this good place to continue discussion?

Andy and Daniel,

yes. lets focus on Web Services module instead this. Its VERY insecure module. Web Services + OAuth modules are much more reliable and safe.

regards,

massa

Suppose this status more real...
@Dave If webservices can transfer email - there's no need to remove required attribute from email field