CiviCRM Community Forums (archive)

Seems to have something to do with the google openid url. My first (admin) account has an openid url of https://www.google.com/accounts/o8/id?id=AItOawnc0h....... Somehow the CiviCRM install script got this big long code into the database. But for the additional users I was putting http://google.com/accounts/o8/id as the openid url.

I'm guessing that I need to determine that big long code for the other google openids I want to use. Does anyone know how to find the code?

I am having this problem too.  The initial id was able to set up correctly but I can't manage to log in under any others.  I have tried using Google and Yahoo openids.  For Google, I tried entering both http://google.com/accounts/o8/id and the actual long Google openid address (which I managed to figure out from another site).  The allow login box was checked, the ACL permissions looked ok, etc.  Couldn't get it to work with Yahoo either.  I get the "Login failed" page every time.  Hopefully this can be fixed soon as I just started using CiviCRM and really like it but need to be able to create other ids that can log in as well.  Thanks!

This doesn't work in 3.0. You can't use Google OpenIDs for more than one account (and I'd be very cautious before using it for any of them). This is because Google (and others, like Yahoo) use OpenID a little differently than providers like myopenid.com. The issue is that you don't get a unique URL for your OpenID endpoint, but a shared URL where you authenticate your Google / Yahoo / etc. account.

Here's the bug report for it: http://issues.civicrm.org/jira/browse/CRM-5131

I'm working on fixing this for 3.1, but could use some help if anyone wants to work on it. We basically need to replace the existing workflow for creating new users (i.e., create contact, enter OpenID URL, check allowed to login) with a new one that goes something like this:

1. Have new user attempt to login to your CiviCRM instance. CiviCRM should deny the login but ask if they'd like to request a new login. If they click on the request new login option, save their OpenID credentials, especially the endpoint URL, claimed ID, and display ID returned by it (assuming they successfully authenticated w/ their OpenID provider), and go to step 2. Also provide the OpenID dropdown / input box here for folks who just need to try again.
2. Send a message to the administrators group saying a user has requested access to the system. Refer to them by their display ID and give the admins a link they can go to to approve or reject the login request.
3. If approved by an admin, require the admin to complete a basic profile for the new user, at the very least e-mail address. Then e-mail the new user at that address letting them know their login request has been approved and link back to the CiviCRM login page.
4. If not approved by an admin, just drop everything.

Anyone have time to help me put that together?

this has not been fixed for 3.1 either. If you'd like to help fix and address this issue that would be great. Check:

http://civicrm.org/blogs/lobo/dropping-support-civicrm-standalone-v32

Would be great for a group of folks to step up and become the maintainers of the standalone project

lobo

* User management / granular permissioning to various CiviCRM features.
* Exposing 'themed' constituent-facing interfaces for online contributions, event registration, membership signup and renewal, other data collection / updating via profiles.