This works for me, at least from other Drupal sites:

function openid_provider_user_url($uid) {
  if (is_object($uid)) {
    $uid = $uid->uid;
  }
  # HACK: user 1 gets domain name
  if ($uid == 1) {
    return '';
  }
  return sprintf('user/%s/identity', $uid);
}

But of course this requires at least a setting somewhere.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

Any user can use the site root as a handle... the actual OpenID identifier will be resolved upon authentication.

What am I missing?

okokokok’s picture

Well, I've used mydomainname.org as my OpenID first as a delegation to myopenid.com and then from WordPress. Both of these OpenID's were stored as mydomainname.org. Now I switched to Drupal and I have to apply this hack to use the same OpenID with the sites that I've used it at before, otherwise it's not recognized and comes out as mydomainname.org/user/1/identity - which means I can't log in to all the existing sites. I hope this is clear enough :)

sashainparis’s picture

Define your variable in settings.php: site_openid_user
Or propose a new field in the openid provider settings page: admin/settings/openid-provider
As a simple text field or a user autocomplete field if you want to make more fun!

function openid_provider_user_url($uid) {
  if (is_object($uid)) {
    $uid = $uid->uid;
  }
  #Define user who gets domain name as openid page
  if ($uid == variable_get('site_openid_user',1) ) {
    return '';
  }
  return sprintf('user/%s/identity', $uid);
}
sashainparis’s picture

Status: Active » Needs review
roderik’s picture

FileSize
4.11 KB

Agree with #2. Implemented idea from #3.

The code needs to be adjusted to account for empty output from openid_provider_user_path(), though. Did that too.

[ Note: the included patch is against a file which already has #861016: Prevent urls from getting language treatment applied. I hope that's OK. Let me know if not.]

roderik’s picture

Title: Allow user 1 to use site root as OpenID » Allow one specified site user to use 'site root' as OpenID

.

roderik’s picture

FileSize
4.11 KB

Not good: '%user' == 0 yields TRUE.
Which means my patch had the effect of making users' identity page inaccessible (because the link disappears from the menu cache).

Fixed patch attached (which makes the variable_get() default argument -1 instead of 0)

anarcat’s picture

Status: Needs review » Needs work

Can we get testing from a third party here?

The patch is not done according to drupal.org's standards, as it's from the drupal's root directory, see https://drupal.org/patch/apply (which will incidentally give you credit in the git history).

Also, documentation for the new function is necessary.

I do not understand why those are necessary either:

+          if ($src) {
+            pathauto_create_alias('openid_provider', $op, $placeholders, $src, $account->uid);
+          }

This patch also doesn't apply:

anarcat@marcos:openid_provider$ curl https://drupal.org/files/issues/722114-7.patch | patch -p4
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4208  100  4208    0     0   6400      0 --:--:-- --:--:-- --:--:--  7706
patching file openid_provider.module
Hunk #1 succeeded at 113 (offset -2 lines).
Hunk #2 FAILED at 125.
Hunk #3 succeeded at 165 (offset -2 lines).
Hunk #4 succeeded at 184 (offset -2 lines).
Hunk #5 succeeded at 375 (offset -2 lines).
1 out of 5 hunks FAILED -- saving rejects to file openid_provider.module.rej

Hopefully those can be fixed and explained!

Dane Powell’s picture

Status: Needs work » Needs review
FileSize
4.17 KB

Re-roll of #7.

Checking $src is necessary because if it's empty we will effectively be trying to create an alias for the front page, right? (I haven't actually checked this)

Dane Powell’s picture

Priority: Minor » Normal
FileSize
4.17 KB

Sorry, syntax error in #9- I've tested this on my own site and it works great.

anarcat’s picture

Status: Needs review » Needs work

So here's another review, but unfortunately, I see that some of my concerns were not answered, or not completely. I tried to give a more exhaustive review here.

+++ b/openid_provider.moduleundefined
+++ b/openid_provider.moduleundefined
@@ -114,6 +114,9 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {

@@ -114,6 +114,9 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {
         if ($account->name) {
           $placeholders = pathauto_get_placeholders('user', $pathauto_user);
           $alias = pathauto_create_alias('openid_provider', $op, $placeholders, $src, $account->uid);
+          if ($src) {
+            pathauto_create_alias('openid_provider', $op, $placeholders, $src, $account->uid);
+          }
           cache_clear_all($alias, 'cache_page', FALSE);
         }
       }

this looks like it's adding a duplicate alias, why is this done?

+++ b/openid_provider.moduleundefined
@@ -114,6 +114,9 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {
@@ -123,7 +126,10 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {

@@ -123,7 +126,10 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {
       // If the user is deleted, remove the path aliases
       if (module_exists('pathauto')) {
         $account = (object) $account;
-        path_set_alias(openid_provider_user_path($account->uid));
+        $src = openid_provider_user_path($account->uid);
+        if ($src) {
+          path_set_alias($src);
+        }
       }
       break;
     case 'view':

Is this really related to this feature? This seems to me to be basic error checking... Which is okay, but maybe should be split in another patch...

+++ b/openid_provider.moduleundefined
@@ -123,7 +126,10 @@ function openid_provider_user($op, &$edit, &$account, $category = NULL) {
@@ -174,6 +180,9 @@ function openid_provider_user_path($uid) {

@@ -174,6 +180,9 @@ function openid_provider_user_path($uid) {
   if (is_object($uid)) {
     $uid = $uid->uid;
   }
+  if ($uid == variable_get('openid_provider_root_user', -1)) {
+    return '';
+  }
   return sprintf('user/%s/identity', $uid);
 }
 

-1 is weird, why not use the same default as below? ('')

+++ b/openid_provider.moduleundefined
@@ -190,6 +199,23 @@ function openid_provider_admin_settings() {
+    '#description' => t("<p>The OpenID (identity path) for users on this site is of the form %userpath. One user can use the 'site root' (%rootpath) instead.</p>
+      <p>It is usually not necessary to set this, but it's applicable for someone who is already using this 'site root' as their identity path, and is switching to this Drupal module for an identity provider.</p>",
+      array('%userpath' => openid_provider_user_path('%user'), '%rootpath' => $rootpath)),

Please mention how to disable the feature (leave empty?).

I think this is a pretty cool feature, but I just want to make sure it is really solid, as we are now in maintenance mode on the 1.x branch and I am hesitant in adding new features at this point. Maybe a dev branch would be necessary... ? So please do make sure you test with and without the feature enable before marking RTBC.

Finally, thanks for the patch!

roderik’s picture

Status: Needs work » Needs review
FileSize
5.08 KB

Anarcat: thanks for the detailed attention. Sorry mine was slipping.

#1 duplicate alias was an error in the re-roll. The patch has now been changed to suit the changed code in -dev.

#2 it's related, in that openid_provider_user_path() could never return an empty string before. This is the only situation where this is possible.

...at least, if we want to keep it this way. I added some comments that align with the existing behavior; see the next point.

#3: no, -1 isn't weird, since the variable holds a numeric UID. And we don't want to mistakenly have openid_provider_user_path() return '' if someone calls this function for UID 0, since it isn't returning '' now. (Agreed? See comments. I don't know, it's not my code... ;) )

Actually, the '' default (not -1) is the weird one; for consistency it can be changed to:

+  $rootuser = variable_get('openid_provider_root_user', -1);
+  if ($rootuser == -1) {
+    // Display empty sting as #default_value.
+    $rootuser = '';
+  }
+  elseif ...

so I did that and added more comments and extra value-checking.

Dane Powell’s picture

I applied the patch in 12, and I'm running into this bug, which I think must be because of the patch: #1913714: Cannot log in to Stack Overflow

okokokok’s picture

It would be nice if there were a patch for D7.

I gave it a quick try to just hack something simple (like the patch that started this issue), but unfortunately in vain.

Dane Powell’s picture

Status: Needs review » Needs work

#12 works only for sites that don't support XRDS (e.g. those using the Drupal core OpenID module) . However, most sites (such as Stack Vverflow) still won't work with this patch.

The problem is that the XRDS module is not passing the user account to openid_provider_xrds(). A hack around this is to add the line $account = user_load(1); to openid_provider_xrds(). I'm not sure what exactly the proper fix is.