• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Incorrect subdomain behaviour

Status
Not open for further replies.
G

Gorian

Chevereto Member
▶🚶‍Reproduction steps
  1. Setup Chevereto at a third level domain (I.E. img.domain.com)
  2. Create a wildcard DNS certificate for the fourth level domain (I.E *.img.domain.com) (https optional)
  3. Go to Dashboard > Settings > Routings and enable "Username subdomain"
  4. Description states "Enable to use https://username.img.domain.com for use profiles"
  5. Try to navigate to your root chevereto domain or any user domain
  6. Chevereto redirects you to your root domain (I.E. domain.com)

😢Unexpected result
I expected Chevereto to do as it told me, and "use https://username.img.domain.com for use profiles". Instead, it expected to be installed at the second level domain only, and redirected me to this after enabling this feature. This is in direct opposition to the stated function, where the description stated it would work with the current domain.


📃Error log message
There should be no errors, as the behaviour is doing as programmed - redirecting me, only to the wrong domain.
 
Subdomain wildcards are intended to be used only at root level. Sub-domain wildcards on top of a sub-domain won't work.
 
  1. Why? That doesn't make any sense
  2. That should be noted somewhere, as it's clearly telling me it should work:
1547580650594.png
 
The subdomain wildcards should be considered a beta feature, highly experimental and the fact that I'm telling you that they won't work in sub-sub-domains is because I know what I created and I know that it won't work in these cases.

Keep in mind that this is called "subdomain wildcards" because it works on sub domains, it wasn't created to support sub domains of a given sub domain.

If helps, I will add a conditional to disable this feature when running under a sub-domain.
 
I guess I just assumed it wouldn't care about what "level" of DNS it's hosted on, and would just say "This is my root, this is subdomains of my root, use those".

and, in general, I would disagree that only 3rd level domains are subdomains, and instead say, anything one level down from a given root, in context of the subject, is a subdomain.

For example, `domain.co.uk` - Technically speaking, in relation to how DNS functions, `.uk` is a *subdomain` of the root domain `.`, while `co` is a subdomain of `uk`, right? and `domain`, in context, is a third-level domain compared to `domain.com`, yet because you can't buy domains at `.uk`, and only certain second-level domains like `.co.uk`, etc. So, it's all a matter of context.
 
Sure, thanks for the insight. I don't doubt that in the future this will support any kind of sub-domain.
 
(huh, can we not edit after a certain time or something?)

No problem, thanks for making a great product and responding to users! I'll keep an eye out for an update to this feature and help test it out. I have all the other infrastructure in place 🙂
 
I've noticed that the thing that makes unusable sub-sub-domain wildcards will cause issues when using domains like "domain.co.uk" or any of that kind. To address this, I've tweaked the implementation to support any level sub-domains.

The patch will be available in the next revision.
 
Status
Not open for further replies.
Back
Top