Jump to content


Senior Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


bluesteam last won the day on August 24 2019

bluesteam had the most liked content!

Community Reputation

5 Neutral

1 Follower

About bluesteam

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good point. Next time I'll remember that 😃
  2. I have often received a query from a client asking why he/she received a certain bounce-back and I have to investigate and then find that the RAW contents displays the actual textual/html content as garbled or scrambled. The headers are visible but the content is not. I simply meant that a server admin is not sitting waiting to read other peoples email just so he can click a URL that has a hash in it. I never disputed the fact that bots and sniffers could be a potential risk. But it really doesnt matter. It's off-topic. My below point still remains:
  3. I don't think it is fair to say that I'm being cavalier about any of this. If I was, I wouldn't bother discussing any of this, not to mention that I would not bother doing my part on using security wherever I can using SSLs on WHMCS and websites or making sure that email clients are configured to use SSL etc. So why in certain scenarios is the mail that was sent unreadable in a bounce back? These are honest questions and I raise these questions in fear of being accused again of being cavalier which I feel I am definitely not. 😉 Nevertheless, the reason we even arrived at this level of detail about security is that it was suggested to use a hash in a url for accepting quotes and that was rejected by most people in this thread because it is obviously not secure to log in rather. I don't dispute that. My point is this... I feel that this discussion is a little pointless because millions of platforms all over the world incorporate hashes in their urls for verifying many events and none of them are complaining about such things such as sniffers and bots and transmission breaches during transport or someone else clicking the links that they sent to a recipient etc etc. The use of hashes in the url is clearly not such as big of an issue in the way it is made out to be here in this thread if it is so widely used every single day. So I personally don't see the problem in using them and don't feel it is worth our time debating whether we should or should not use them based on the wide use of them across the world.
  4. Well if you include email replies as an acceptance method then that isn't using the WHMCS quoting system the way it was intended to be used. So if you know of any other way that uses the WHMCS quoting system to it's full expected potential without the client being forced to first register an account and then forcing him/her to log in after to accept the quote and having the quote history linked to the new clients account then I would really appreciate it if you could tell me because I need an answer to this problem.
  5. Based on the fact that if you are not using SSL with your SMTP sending on your WHMCS installation then you really shouldn't even be a web host at all. And based on the fact that 90% of modern mail clients that are available today default to using SSL and if a mail client is not using SSL then it was probably manually configured like that by the end user. I don't think I have set up a mail client in the past few years that isn't using SSL. Not to mention the fact that I'm pretty sure there aren't any server admins out there that are just waiting and watching for emails to arrive in the mail server queues directly from a web host using WHMCS having the word Quote in the subject just so they can accept it to prove that it can be compromised.
  6. Especially when we are hosting the domain! It's only our responsibility to secure the server. It's not our responsibility to make sure the client secures his password to his mailbox. We can tell them to use strong passwords and even implement configurations that force them to use strong passwords but we can only do so much! Regarding sub-accounts, if the client has added ANYONE to his list of sub-accounts and allows them to accept or reject quotes, then that was his choice. It is not my problem if he/she creates those sub-accounts and puts their trust in someone else. We as admins should not be adding people from the backend on behalf of the client allowing the client to point the finger at us and even if we do do it on their behalf, we should not be doing it without a support ticket requesting this so that we can refer back to it in future. The client should use the tools from within his dashboard. And the quoting system can also be coded in such a way to log who accepted the quote when they clicked the link. The link that is generated can be created PER email that goes out to each recipient so that it can be tracked as to WHO accepts the quote but regardless of how you look at it, there is definitely room for improvement here.
  7. That is true but most mail these days is anyway encrypted. I say MOST mail... Then how do millions of websites around the world circumvent this that use hashes? Maybew WHMCS can learn from them and if not, then that would implt all of them should find an alternative method and WHMCS is doing it right and them wrong? It's obviously implied by all the talk on this thread advocating NOT to do it with hashes. The word security has been used in a negative context a few times on the thread in relation to using hashes in the URL: You referred to security yourself in your first reply. Sure you said that logging is still a better option but you referred to security nonetheless which implies that it is not as secure. I challenge why it is a real issue at all when so many platforms use the hash in the url method. So I am not making things up when I pose the question about it being impled that hashes are insecure based on the content in this thread when it is so widely used across the world. So, I will maintain my position, if using hashes in urls is not best practice because of the potential pitfalls, who of this group of people here is going to tell them all that it's a bad idea and it should not be done? I am of the opinion that hashes have become standard practice all across the world and if it can be used to verify email accounts or using it in other method's, it can't be that bad. right? I just think that it should be an option available in the WHMCS to allow this if we desire it to be this way. In order for us as WHMCS admin users to send quotes to new potential clients, they now first have to be told to register an account BEFORE they can even be quoted. 90% of new clients won't want to do this. So, the only way around that is to quote the user from a phantom account which means if they ever do accept the quote that we manually accept in the WHMCS system on their behalf, it's never going to be linked to their account when they DO finally sign up so they cannot even access the quote using Billing -> My Quotes in their dashboard to see what was sent them when logging in to their own accountThis is what I meant when I said it is circumventing the whole quoting process intended by WHMCS developers when we ask them to accept the quote in an email and not using the WHMCS system. I hardly believe that this was the intention by the WHMCS developers when they implemented the quoting system. They wouldn't want the client to have to reply in an email and bypass the quoting system. So, at present the only way to correctly process quotes and have said quote linked to the clients account for them to also access it properly without us admins from fiddling in the database is for the NEW potential client to first have a registered account so that the quote history can be tracked by both us and the client. After that, if the client is an already registered client, He/She still has to be logged in to accept the new quote and the argument can be made, why not save their username and password in their browser as you stated here: Well, not everyone believes in the security of saving their passwords in their browser. I am not one of those but many people still don't do it. I just feel that the quoting process can be improved and should be improved!
  8. Dude this is very cool! Nice work there! So my question is this, why is this considered INSECURE?!? I don't consider this INSECURE because we expect the email that goes out to the client to be delivered to the email address on the WHMCS system. We don't expect this mail to end up in anyone elses mailbox and if it does, because the mailbox is compromised, then that is not our problem nor is it our fault. But this is anyway unlikely So my question remains, why is it so insecure to have an hash in the url to accept a quote? MANY systems use this approach!
  9. There is clearly something I am not understanding here. Why is it NOT a security compromise when other systems and websites all over the world can send a client an email verification link with a hash in the url and yet WHMCS considers this a security compromise on their own system for their own email verification process as well as the quote process?
  10. Yh, by doing it the way you are doing it now really circumvents the whole quote process. Really silly that the email link doesnt have a simple encrypted key in the URL that is like an email verification link.
  11. I have a very difficult client that refuses to take the time to log in to accept a quote because be forgot his password and complains that he doesn't have the time to go through the password reset process. I can accept it on his behalf but I would prefer not to because I want to be able to say later that he accepted the quote himself without him accusing me if doing it for him. Is it possible to allow a client to simply click the link in the mail and then display the ACCEPT button without the client having to log in first??
  12. I already have this enabled. But this credit is created AFTER the invoices have been generated. 😞 I don't understand how WHMCS doesn't have this feature. Oh well, nothing is perfect I guess. Thanks Kian 🙂
  13. Hello, This might seem like a simple question to most and I apologise upfront if it is a really easy thing to do but I can't seem to figure it out. I have a client that pays a monthly amount using the Add Funds facility because he is too lazy to log on to the system and pay his invoices so he just has a standing order that pays a fixed amount every month. If this client has 4 or 5 invoices, I have to go in to each invoice and click on the CREDIT tab and apply the credit there for each individual invoice. s there a way to multi-select the 5 invoices and apply the credit available on the clients account?? I would appreciate some guidance here. Thanks Brett
  14. ok, so the problem was related to the .htaccess file containing the following PHP entries: I removed these and everything worked. So it's clear the old host used a different PHP setup than the new host.
  15. So on the new server, the SOAP module wasn't enabled. This was preventing the communication between the server and the token servers. After I enabled the SOAP module I went through all the modules to make sure that the necessary ones were enabled. I retested and I was now able to get past the communication error. However, now the barcode is not rendering. it's simply not generation. Any idea??
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated