Bypass whois-function in case of downtime or false positives?

[-M-]

I am wondering about something. Sometimes WHOIS-servers give false positives (for example with .nl) as in the domainname has already been taken or is in use. Also sometimes there is maintenance on the WHOIS-sever and isn't working.

 

In the above mentioned cases, the customer cannot register a domainname and / or proceed to place an order. Which will mean you will lose potential income.

 

Wouldn't it be possible to add some kind of button / check field to skip the domain lookup in cases of this, so they still can proceed with their order?

 

During testing our WHMCS site I noticed that I received a lot of false positives (on random occasions) with mainly .nl-domains. It also happened a few times with .eu and .be as well. It would show the domain was already taken, but this was not the case. Therefor there should be an option to bypass the check. For example a checkmark function with the text "I think the result is false and the domainname is free. Use this domain for registration."

 

Maybe this option is already included or maybe there is a workaround for this already, but I couldn't find it.

 

FYI: we process all orders by hand; nothing automated.

 

Regards

[brian!]

if you start getting false positives from a whois result, the first thing to check is if the whoisservers.php entries for those TLDs are correct - in the latest v6.2.2 release, they are for those three TLDs.

 

the next thing to check is whois lookup limits - I suspect this may be where your issue lies... you might be hitting those whois query limits - especially for .nl domains...

 

https://www.sidn.nl/whois

 

In a twenty-four-hour period, you can make up to five hundred status enquiries from any given IP address. However, you can only look up the details of an existing domain name's registrant fifteen times a day.

additionally, I think it will block you (which WHMCS will interpret as a domain not being available) if you try to make too many lookups in a short period.

 

I suppose if .nl is in your alternate TLDs list in WHMCS, you could easily hit that limit per day - e.g if a customer was searching for a .com, it would also lookup the .nl too - it might be worth taking a look at your Whois Lookup Log (utilities -> logs -> whois lookup log) and seeing how many searches have been made for .nl domains.

 

if you are doing too many lookups, you might need to consider removing .nl from your alternate TLD list - but if this only occurred during testing (when you were making lots of lookups), but not in the public site, it might not be occurring.

 

depending on your registrar, it may be possible to bypass that limit if they offer a WHMCS-compatible API method instead of WHOIS - but I don't know for certain.

 

if you are hitting lookup limits, and can't use an API solution, you could change your whoisservers.php setting for .nl domains to...

 

.nl|whois.domain-registry.nl|.

that should (I think!) show all .nl domains as being available and so would allow the order to progress as normal... if you're going to do this, you'd probably need to add some text to the orderforms to say the .nl domain may not be available etc.

[-M-]

Thanks for answering brian!, however our website isn't live yet (so I am the only one using it), so I doubt I hit any kind of limit, let alone 500 queries. More importantly; the IP (of the website) is already white-listed with the SIDN. So it shouldn't be limited at all. The same goes for .eu and .be.

 

I am also not looking up the owner details; only check if a domainname is available or not for registration. It's when you order a webhosting package or a stand-alone domain (not the domainchecker or whatever it's called).

 

Furthermore; the solution which you mentioned isn't a one I am going to use. Because it will not work for domain transfers either anymore (I guess).

 

I experienced the false positives several times already by myself, while the website is not even live yet. So I am getting a bit worried about what's going to happen when the site actually will go live. If several customers get that message, than they won't order anything with us.

 

I think, in this case, a more viable solution would be to add an option so in case of a false positive, they still can proceed with their order. Maybe it's a stupid idea, but I think it's useful. Especially in cases of maintenance. It's weird that nobody has even give this any thought.

 

Anyways, I have submitted this to feature requests. If they don't think it's a good idea, I will ask for a custom made hook otherwise.

 

Thank you nevertheless for answering. Your input is always appreciated. )

 

Regards

 

PS: I am using the latest version 6.2.2

Edited February 23, 2016 by MvdL1979
Added info about current version. :)

[brian!]

Furthermore; the solution which you mentioned isn't a one I am going to use. Because it will not work for domain transfers either anymore (I guess).

that's a good point that I never thought of - it would indeed prevent transfers... unless you then modified the transfer page not to check - but let's not go do down that road...

 

I experienced the false positives several times already by myself, while the website is not even live yet. So I am getting a bit worried about what's going to happen when the site actually will go live. If several customers get that message, than they won't order anything with us.

I can hit false positives (or more accurately a warning response) on the admin whois lookup with .nl if I search too often too quickly - our IP isn't registered with SIDN, so that issue might not apply to you... but if that occurs on the client side in the cart, it would appear as a false positive.

 

I think, in this case, a more viable solution would be to add an option so in case of a false positive, they still can proceed with their order. Maybe it's a stupid idea, but I think it's useful. Especially in cases of maintenance. It's weird that nobody has even give this any thought.

the problem is how can WHMCS detect if it's a false positive or a positive positive (if you see what I mean!) ? perhaps if the whois response didn't contain the TLD string from whoisservers.php - but even then, that could be caused by the whois server having multiple response options (reserved, premium etc); an incorrect entry or many other reasons... I just think this could cause more problems and confusion than it solves.

 

it almost feels like you're trying to find a solution to a problem that no-one else is having... i'm certain that it's not the WHMCS whoisservers settings causing this (assuming yours are correct) - so then you look at some of the alternatives... the registry sending error whois messages that WHMCS will interpret as domain being registered? your server's connection timing out to the registry (resulting in same message)? a template misconfiguration or cache issue? I can think of others...

 

Anyways, I have submitted this to feature requests. If they don't think it's a good idea, I will ask for a custom made hook otherwise.

even if they do, good luck with seeing the feature added in your lifetime!

 

personally, i'd be looking at the reasons why these false positives are occurring and not trying to tweak WHMCS to ignore them... maybe ultimately you'll have to, but it should be a last resort.

[-M-]

that's a good point that I never thought of - it would indeed prevent transfers... unless you then modified the transfer page not to check - but let's not go do down that road...

 

Sometimes I can do think straight.

 

 

I can hit false positives (or more accurately a warning response) on the admin whois lookup with .nl if I search too often too quickly - our IP isn't registered with SIDN, so that issue might not apply to you... but if that occurs on the client side in the cart, it would appear as a false positive.

 

Maybe I just did it to fast, however when I re-check them straight away, sometimes it actually does work. I already added an information screen about it for customers. So if this happens they need to retry again. However sometimes it keeps showing it's not available. Also during maintenance. There is no information at all about that. Past week they had maintenance from 7:00 PM till midnight or something. Sigh.

 

 

the problem is how can WHMCS detect if it's a false positive or a positive positive (if you see what I mean!) ? perhaps if the whois response didn't contain the TLD string from whoisservers.php - but even then, that could be caused by the whois server having multiple response options (reserved, premium etc); an incorrect entry or many other reasons... I just think this could cause more problems and confusion than it solves.

 

Yeah I think so. But .nl doesn't have premium names and their whois only sends back free or not available (or something similiar at least). Same goes for reserved names (which result in not available)

 

it almost feels like you're trying to find a solution to a problem that no-one else is having... i'm certain that it's not the WHMCS whoisservers settings causing this (assuming yours are correct) - so then you look at some of the alternatives... the registry sending error whois messages that WHMCS will interpret as domain being registered? your server's connection timing out to the registry (resulting in same message)? a template misconfiguration or cache issue? I can think of others...

 

 

Yeah it's mee against the world it seems. I only have weird issues with WHMCS so far and things other people never experience. Same with the bug I reported (almost 2 months ago) and they are still working on it apparently (asked about it yesterday). Seems nobody else had noticed it. Try to transfer a single domain and then selected the recommended domains as well, then you have enter an EPP code for them all (including newly to be registered domains)

 

even if they do, good luck with seeing the feature added in your lifetime!

Yeah, thought so...

 

personally, i'd be looking at the reasons why these false positives are occurring and not trying to tweak WHMCS to ignore them... maybe ultimately you'll have to, but it should be a last resort.

 

Well for the time being I will leave it alone. I think I will create a support ticket about it as well. I think there should be an option to go ahead even if it thinks the domainname is taken. Every week there are more TLDs and more organisations who register those (new) TLDs in / for different countries. This means different maintenance schedules as well. During maintenance, no matter which organisation, their WHOIS will not work, which results in a false positive and customer cannot order anything.

 

At the very least, the customer should get a notice about the whois being down for maintenance or whatever. But that would even involve more coding, rather than a simple checkbox which makes it possible for the customer to continue... Right?

 

Anyways, thank you for your input as always.

 

Regards

[WHMCS John]

Hi,

In v6 and above, domainchecker.php will no longer block the ordering process due to a temporarily issue with a whois server, and the customer will be able to proceed with the ordering process.

[-M-]

I think you misunderstood John; I didn't mention the domainchecker.php, but the one on the orderforms templates itself!

For example in the 'cart' template: adddomain.tpl.

 

I think that's the template I mean. If the whois is down, having maintenance or returns a false positive, the client is unable to return. This is not related to the domainchecker.php.

 

And I am running the latest version; 6.2.2 or something.

[-M-]

Well apparently it's become quiet on John's behalf.

...I am guessing they are fixing it as we speak.

[brian!]

Well apparently it's become quiet on John's behalf.

...I am guessing they are fixing it as we speak.

I can't tell if you're being optimistic or sarcastic - i'm guessing the latter!

[-M-]

I can't tell if you're being optimistic or sarcastic - i'm guessing the latter!

 

 

...but, I am ready to be surprised though.

[-M-]

John is this fix almost ready? You are taking your time on this.

...last reply was 2 weeks ago.

 

Thank you for taking care of your customers!

[WHMCS John]

Hi,

I've not been able to reproduce the situation where a domain order is blocked due to a whois server failure on cart.php or domainchecker.php in v6.2.2 (See attached).

[-M-]

Hi,

I've not been able to reproduce the situation where a domain order is blocked due to a whois server failure on cart.php or domainchecker.php in v6.2.2 (See attached).

 

Well that is weird; I had it several times. I cannot re-produce it at the moment, but I will keep this thread open.

As soon as I notice it happens again. I will post screesnhots of it. I will also look into the logs then.

 

One thing I did notice; if I do a domain search (on cart.php) several times after each other. The whole system hangs. Nothing works for 60-90 seconds. I cannot access anything WHMCS related (ordering pages, admin panel, all unavailable). What is the recommended execution time for PHP scripts/commands in regards to WHMCS in general? Maybe I have it to high and should lower it considerably?

 

Regards

[-M-]

Well since I restarted working on our new website (with WHMCS) this week I finally had the same issue again with a false positive.

 

I took 2 screenshots what WHMCS is showing and if I check the .nl domainname elsewhere. I have included them both as well. See below.

 

 

 

For your information; this was the first whois check / lookup since today. So there is no way this is limited to an IP-number. There is a button underneath it all (didn't take a screenshot of it) which states "Continue", but when you click that you need to enter the domainname again. This is not what I mean. There should be a button like; "This domainname is not taken, I am sure of it. Continue."

 

In that way customers can still place an order with that particular domainname, instead of leaving our website and go over to a competitor.

 

If you try it a few mins later again, with the same domainname, then it suddenly does work in WHMCS.

 

This is what I meant with false positives and being able to continue anyways. Which the customer should be able anyways.

[brian!]

For your information; this was the first whois check / lookup since today. So there is no way this is limited to an IP-number. There is a button underneath it all (didn't take a screenshot of it) which states "Continue", but when you click that you need to enter the domainname again.

when a domain is available, it is passed to the next page using hidden fields; when a domain is not available (or WHMCS thinks that it's not), those hidden fields aren't used and therefore nothing is passed.

 

This is not what I mean. There should be a button like; "This domainname is not taken, I am sure of it. Continue."

 

In that way customers can still place an order with that particular domainname, instead of leaving our website and go over to a competitor.

in order to give the user the option to add the domain to the cart when WHMCS thinks that it's not available, you should just need to make a minor tweak to standard_cart/domainoptions.tpl and change...

 

        {elseif $status eq "unavailable"}
           <div class="domain-checker-result-headline domain-checker-unavailable">
               {$LANG.cartdomaintaken|sprintf2:$domain}
           </div>
       {/if}

to...

 

        {elseif $status eq "unavailable"}
           <div class="domain-checker-result-headline domain-checker-unavailable">
               {$LANG.cartdomaintaken|sprintf2:$domain}
           </div>
           <div class="text-center">
           <button type="submit" class="btn btn-primary">
               The domain "{$domain}" is not taken, I am sure of it. Continue.
                <i class="fa fa-arrow-circle-right"></i>
           </button>
           </div>
           <input type="hidden" name="domains[]" value="{$searchResults.domainName}" />
           <input type="hidden" name="domainsregperiod[{$domain}]" value="{$searchResults.shortestPeriod.period}" />
       {/if}

if you do, then you should see something similar to below...

 

 

pressing the button will add "microsoft.nl" to the cart (even though it is definitely registered!!).

 

the above code works fine if there is only one result (e.g the alternative TLDs are also already registered), but if there are alternative options, e.g if you search for 'whmcs.nl', it is registered and there are many other alternative 'whmcs' domains available (.org.uk, .ventures etc), then ticking any checkboxes will add those domains to the cart - but it will also add whmcs.nl by default whether the user wanted to or not.

 

the workaround would be to replace your button with a checkbox, along with a message telling the customer to tick the checkbox to add the domain to the cart - that way, the "unavailable" domain is only passed to the cart if the customer ticks the checkbox.

 

        {elseif $status eq "unavailable"}
           <div class="domain-checker-result-headline domain-checker-unavailable">
               {$LANG.cartdomaintaken|sprintf2:$domain}
           </div>
           <div>
           <input type="hidden" name="domainsregperiod[{$domain}]" value="{$searchResults.shortestPeriod.period}" />
           <label>
           <input type="checkbox" name="domains[]" value="{$searchResults.domainName}" class="suggested-domains"/>
           If you believe that the domain "{$domain}" is not taken, tick the box and it will added to your cart.
           </label>
           </div>
       {/if}

 

with no checkboxes ticked, pressing "Continue" will just return you to the search page again... but if you tick one, or more, checkboxes, those domains will be added to the cart and the order process can continue.

 

from a design point of view, it might be cleaner to either centre the checkbox and text, and/or add a space between the checkbox and text - but I can leave you to adjust the output to your own needs.

 

if your site uses multiple languages, then you'll need to adjust the text line to use a Language Override instead... I just hard-coded the language for quickness and simplicity!

[-M-]

Wow. Brian! excellent work / solution. I don't understand why WHMCS didn't come up with this.

I am not concerned with other languages, so your solution is *perfect* for me!

 

Many, many thanks Brian! I will be sure to put this to very good use!!

 

PS: WHMCS in case you are reading this, why weren't you able to pull this off? Nevertheless, all credits and thumbs up for Brian!