I have 50 domains in various stages of readiness. My customer wants to review the websites before I make them "active" (live). I thought the easiest way to do this was to make all sites in development "inactive" and then create a role for the reviewer. The permissions I thought I needed for that role include:

Domain module - access inactive domains
Node module - access content

This role doesn't seem to be working. Is there more to it? All I want to do is to expand the anonymous user privilege to include viewing content on inactive domains.

Thanks.

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: bug » support

What's not working about it? Where is the access being denied? Is the user being redirected away from the inactive domains?

Also make sure the nodes are published and the domains are not in maintenance mode.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Note that rejected inactive domain requests are logged. So check the watchdog. If nothing's there, it's either a server or an alias issue. Or the user doesn't have the proper role.

dpb’s picture

dpb commented

Thank you for your help. I can see I mixed up the "Valid domains" action with "Site Status". The "access inactive domains" permission still seems like the solution to my problem, though.

Nodes are / always were published.

I _was_ trying to run domains "active" and "offline". When I was working as the administrator, it was not a problem. I thought I could re-create that for an authenticated user. Currently, my customer's role has only "access content" and "administer site configuration" permission. This allows the user to land at the offline site and enter using the domain.com/user URL. It's probably not the best, but I like the "knock and authenticate" flow.

My problem with running domains "inactive" and "online" is that the user is getting redirected to the primary domain (which I would prefer to keep anonymous, BTW), which is confusing.

From the log:
Type: domain
User: Anonymous
Location: http://inactive.com/
Message: Invalid domain requested by on "inactive_sitename"; redirected to "primary_domain_sitename"

(I notice the empty space between "by" and "on"; maybe a user name is missing?)

Is there a way around the redirect?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Give the role 'access inactive domains' and the redirect should stop. The empty space is because the anon user has no name.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

You probably don't want to give Anon users this ability, however. But I think I see the problem. If you don't share a common top-level (*.example.com), then your users will never be able to login to their domain.

Are you using distinct domains for each user? e.g. myexample.com instead of my.example.com? With the latter, they can log in to the master site and then go to their preview domain.

There are some ways around this, actually, using a custom module an hook_domainload() to conditionally change the valid flag IFF the user is on the login screen.

This might work:

function custom_domainload(&$domain) {
  global $user;
  if (empty($user->uid) && arg(0) == 'user') {
    $domain['valid'] = TRUE;
  }
}

That would allow anon users to access the user page on any domain, which means they could login in. Then they might get redirected if they don't have the 'access inactive domains' permission.

dpb’s picture

dpb commented

All of these sites are independent of each other. The primary domain is independent of all sites, as well. I probably could have worked harder at using the primary domain as a login gateway for reviewers, but I didn't want to confuse people with the extra (primary) domain and the concept of switching domains.

Your code solution seems right on. Unfortunately, I don't have time to test or implement it. My workaround is slightly risky, but it does allow/require my customer to log in and it places the responsibility for mistakes with my customer. There will be an audit trail, as well. All in all, I think I can live with the risk for the relatively short time it will take to review and release these sites.

I hope this helps others. Maybe this could be an enhancement for the future?

Thank you for your help.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Version: 6.x-2.5 » 7.x-2.x-dev
Category: support » feature

It's a very edge use-case. Not sure the best way to support it.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Version: 7.x-2.x-dev » 7.x-3.x-dev
dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented
Issue summary: View changes
Status: Active » Closed (outdated)

I'll close this issue due to inactivity for 14 years and there is upcoming EOL of Drupal 7 in January 2025. While the project's version for Drupal 7 will surely keep providing support for security issues and website breaking bug fixes for Drupal 7, we should try to minimize the open issues for Drupal 7 in the queue as much as possible. A big thanks around for the report and all the efforts in here. Feel free to re-open if you can provide a fix or found an additional related problem which increases the issue priority.