Issue: After Admin1 adds "Custom domain" in settings. Then, no other admins or users can select or use the "Custom domain"

[chrislawso]

In the page kuttserveraddress.com/admin after performing "Add domain", for example www.customdomain.com, the address appears in list "by System" and is not visible and is not available for any user on homepage in "Show advanced options" "Domain" list.

The only method I found is ie Admin1 user must goto kuttaddress.com/settings and perform "+ Add domain" under "Custom Domain" and then only this one user account Admin1 now will have visible the www.customdomain.com on homepage in "Show advanced options" "Domain" list. On kuttserveraddress.com/admin the domain address appears in list "by Admin1@email.com"

If any other admin ie Admin2 or user now tries to add same www.customdomain.com by going to kuttaddress.com/settings and performing "+ Add domain" under "Custom Domain" they get a red error message "You can't add this domain."

Is there any method for sharing a "Custom Domain" ie www.customdomain.com with multiple Admins and several users simultaneously so that everyone can see and have available for use the custom domains on their homepage in "Show advanced options" "Domain" list?

Why cannot multiple admins and users have access to use and create links with custom domains in their accounts? Why is a custom domain restricted to a single account at a given moment in time?

Thanks

[lit-carlos]

This would be so helpful when it comes to user management. Currently, I'm creating a new user for a new custom domain and this is not ideal.

[chrislawso]

In the file server/handlers/validators.handler.js I found the following lines 179-183 which appear to be responsible for rejecting if the domain is already owned by another user or is banned.

.custom(async value => {
      const domain = await query.domain.find({ address: value });
      if (domain?.user_id || domain?.banned) return Promise.reject();
    })
    .withMessage("You can't add this domain."),

I am unfamiliar with most of the code in this project and the design decisions and do not know what other parts of the code are related to this validator. I did find controller functions for managing domains in server/handlers/domains.handler.js where it appears to add a domain to the database with the user’s user_id.

In my environment I have only a very small group of total of two users of kutt and so for me the ideal solution would be to allow all custom domains to be usable by all two users. My quick solution to this problem is to simply create a single new kutt admin user on my kutt instance to which I add several custom domains and I share this username and password with my other real life team admin so we both have access to all the custom domains using the same single account credential.

In other peoples' environments where they may have totally different groups of users and other peoples' domains they may not want sharing of custom domains.

@poeti8 @trgwii at your convenience could you provide any suggestions or guidance so that maybe community can try to help to add new feature support for multi user access to shared custom domains? Thank you

[poeti8]

@poeti8 @trgwii at your convenience could you provide any suggestions or guidance so that maybe community can try to help to add new feature support for multi user access to shared custom domains?

One good way to do it is to add a new configuration, something named like OTHER_AVAILABLE_DOMAINS (since we already have DEFAULT_DOMAIN), which would a be a comma separated list of available domains, and can be used to allow all users to access and use those domains.

[chrislawso]

One good way to do it is to add a new configuration, something named like OTHER_AVAILABLE_DOMAINS (since we already have DEFAULT_DOMAIN), which would a be a comma separated list of available domains, and can be used to allow all users to access and use those domains.

@poeti8 @trgwii OTHER_AVAILABLE_DOMAINS would be set as env variables ?

I was exploring more of the project code and found that the server/views/partials/shortener.hbs file generates the list of available domains for the front end at

          <select 
            id="domain" 
            name="domain" 
            hx-preserve="true" 
            hx-on:change="
              const elm = document.querySelector('#customurl-label span');
              if (!elm) return;
              elm.textContent = event.target.value + '/';
            "
          >
            <option value={{default_domain}}>{{default_domain}}</option>
            {{#each domains}}
              <option value={{address}}>{{address}}</option>
            {{/each}}
          </select>

Displaying additional OTHER_AVAILABLE_DOMAINS in the above select will display additional customdomains but fails validation on execution. I forgot to search and find the related validator code.

I tried some alternate simple tests to see how I can bypass other validators to be able as admin or user to change a domains related user_id and I found two simple bypass methods.

One partial method that is simplest and requires no code changes is in postgres I can perform UPDATE public.domains and SET user_id = x commands that I can individually re-assign domains to particular user. This does not solve the problem for multi user access to shared custom domains because only one user continues to be able to use a domains.

Another partial method that is simple, not elegant, and not advised (because removes a validator from the code that checks if the domain object exists and if it has a user_id property) that tested and works for me as an improvement and as a temporary solution in my deployment scenario is in server/handlers/validators.handler.js file to remove the domain?.user_id || from

.custom(async value => {
      const domain = await query.domain.find({ address: value });
      if (domain?.user_id || domain?.banned) return Promise.reject();
    })
    .withMessage("You can't add this domain."),

This modification allows for example, if user1 has customdomain1.com pre-existing in kuttaddress.com/settings, user2 will be able to successfully add customdomain1.com in kuttaddress.com/settings and user1 will lose customdomain1.com. This does not change or effect pre-existing links generated by any users. This does not solve the problem for multi user access to shared custom domains because only one user continues to be able to use a domains. This may work in small group of users for a user to quickly selfservice to add a pre-existing customdomain to their user account to generate links without requiring admin to perform SQL commands and without requiring to find associated user with a domain to request said different user to delete a customdomain from there account.

At this time I don't have the knowledge or experience to properly implement a complete solution for multi user access to shared custom domains and to include the appropriate validations you require. Maybe someone with more skill is able to produce good code for this feature.

[poeti8]

@chrislawso

OTHER_AVAILABLE_DOMAINS would be set as env variables ?

Yes.

Displaying additional OTHER_AVAILABLE_DOMAINS in the above select will display additional customdomains but fails validation on execution. I forgot to search and find the related validator code.

Well yes, because nothing is implemented yet. I only made a suggestions and the implementation is yet to be done.

I'll see if I can free up a weekend to work on it.

[chrislawso]

@chrislawso

OTHER_AVAILABLE_DOMAINS would be set as env variables ?

Yes.

Displaying additional OTHER_AVAILABLE_DOMAINS in the above select will display additional customdomains but fails validation on execution. I forgot to search and find the related validator code.

Well yes, because nothing is implemented yet. I only made a suggestions and the implementation is yet to be done.

Yes I was fully aware. I was looking at the code and trying to learn how some of the parts of front and back end interact currently.

I was hoping I could offer more help and/or get more people interested and involved in working towards a viable solution.

I'll see if I can free up a weekend to work on it.

Respect.

[poeti8]

I was hoping I could offer more help and/or get more people interested and involved in working towards a viable solution.

Well I think that's just it, adding an environment variable, making it available, validating user requests, and handling redirects.

That's what I think how it should be implemented now at least.

[tommaso82]

to make as few changes as possible to the current code, couldn't we simply exploit the fact that the domains we add from the control panel have an owner = NULL and therefore we could consider all those with owner = NULL public?

[tommaso82]

in validators.handler.js, we could add a sanitization that, as soon as it receives the value of the domain field, immediately transforms the string corresponding to the default domain into null, and only if an address other than the default remains does it retrieve the record from the database to insert it into req.body.fetched_domain; this allows us to unambiguously distinguish “no custom domain” from the system domain, avoid errors due to the search for a non-existent record and provide the next handler with ready-made and semantically correct information. Then in links.handler.js we could insert, at the beginning of the create function, a check that verifies in the database the existence of the domain, the banned flag and the ownership (null owner = public), so as to immediately block any attempt to use banned domains or domains of other users; finally in locals.handler.js we could restructure the user middleware to first retrieve all the public system domains (those without an owner) and then, if the user is authenticated, his personal domains, concatenating them into a single list to pass to the views

[poeti8]

to make as few changes as possible to the current code

Why? Making changes is not a problem. The effort is more or less the same no matter which route I go.

couldn't we simply exploit the fact that the domains we add from the control panel have an owner = NULL and therefore we could consider all those with owner = NULL public?

Not exactly. There should be an explicit mark on the domains that should be available to the public. Now, it can be added as an option there, but again, as I said before I think it's better for it to be part of the website configuration.

[tommaso82]

to make as few changes as possible to the current code

Why? Making changes is not a problem. The effort is more or less the same no matter which route I go.

couldn't we simply exploit the fact that the domains we add from the control panel have an owner = NULL and therefore we could consider all those with owner = NULL public?

Not exactly. There should be an explicit mark on the domains that should be available to the public. Now, it can be added as an option there, but again, as I said before I think it's better for it to be part of the website configuration.

My suggestion was meant as a quick, minimal-code patch—I see how overloading owner = NULL can be confusing. Making it part of the site configuration is indeed a more robust solution.

[mbauwens]

We also ran into this issue with our team. We need a custom domain shared by multiple users. As a workaround, we're currently letting one of our team members generate all of our short links - which is obviously sub-optimal. Any updates or plans for this bug?

[poeti8]

Any updates or plans for this bug?

@mbauwens Bug? Do you know what bug means?