NetLink

I'm having this problem after upgrading to v. 6.0.1. I've reset the modules/widgets directory, and even the whole modules directory and the includes/hooks directory. I've done a "grep" search on the server for "WHMCS_Charts", but found nothing. Obviously, I can't troubleshoot further because the files are encoded. Also, you seem to be having problems with your forum here (editor not loading)... Error: Blocked loading mixed active content "http://forum.whmcs.com/clientscript/ckeditor_config.js?v=422&t=B8DJ5M3" Source File: https://forum.whmcs.com/clientscript/ckeditor/ckeditor.js?t=A7HG4HT&v=422 Line: 2 Error: TypeError: this.editor.textarea is undefined Source File: https://forum.whmcs.com/clientscript/vbulletin_textedit.js?v=422 Line: 1

+1. The transaction reports don't make much sense without a date range filter. Please add it back. This is a very important feature since it's used for accounting.

I'm willing to give it a try. Latest WHMCS is in production use, and we have several dedicated servers, some running cPanel, and a couple of hybrid servers, all running cPanel.

I'm not sure about PCI Compliance in general, but my vulnerability scanning service is failing after the upgrade to 5.1.2. The test that fails is: Sensitive Cookie Missing 'HTTPONLY' Attribute - Medium Severity

I wrote a PHP script that creates a PDF statement on the fly, which the client can download using a unique URL. Mine is set to display transactions in the past 2 years, but this can be changed easily. The script can be uploaded anywhere, it doesn't need to be on the same server or domain as WHMCS. All it needs is the WHMCS database info. What I did then was create an email template in WHMCS called "Client Statement". I entered my text and hashed the client ID, name and email address to create the unique URL. Under a client's summary page, I can then select this template under "Send Email", and the client can then use the link in the email to download the PDF. I can attach the script here. It should works for most clients, but the SQL query might need some work. I remember having to change it once or twice to work with customer credits. I'm pretty sure I was able to get it working, but if you don't use credits, it should definitely work without any modifications. I've attached a sample of the statement, as it looks when it's downloaded. If anyone wants the script, let me know.

On the 12-1208, Matt@WHMCS posted: "For PA-DSS which you raise, it is our responsibility as the software provider to create an application that does not prevent you from achieving PCI DSS compliance." From what I can tell, WHMCS currently does prevent me from achieving PCI compliance. To be fair, there could be other things that currently prevent me from achieving it, but right now, I'm trying to determine whether it's even worth my while trying, or if I need to cancel my merchant agreement and take credit card payments over the phone only. To be honest, I'm not interested in switching to a different billing system. I spent way too much time, money and effort trying to find a solution that works. So, it would be great to have this issue resolved. With regards to PA-DSS, it's my understand that the software needs to be compliant, but to verify compliance, there are different methods. Basically, even if WHMCS is PA-DSS compliant, it doesn't necessarily have to be included on the list of verified applications. For a payment application to be deemed PA-DSS compliant, software vendors must ensure that their software includes the following 14 protections: 1. Do not retain full magnetic stripe, card validation, code or value, or PIN block data. (done) 2. Protect stored cardholder data. (mostly done, I would say) 3. Provide secure authentication features. (not done) 4. Log payment application activity. (done, I think) 5. Develop secure payment applications. (this seems to depend on all other steps?) 6. Protect wireless transmissions. (not applicable, I think) 7. Test payment applications to address vulnerabilities. (done) 8. Facilitate secure network implementation. (not sure) 9. Cardholder data must never be stored on a server connected to the internet. (I'd say this is achievable, but is mostly up to the WHMCS user, I'm guessing WHMCS could simply add an alert to the dashboard to say that database must be on a remote server, if it detects that CC payments has been activated) 10. Facilitate secure remote software updates. (done) 11. Facilitate secure remote access to payment application. (done) 12. Encrypt sensitive traffic over public networks. (done, I think) 13. Encrypt all non-console administrative access. (force SSL?) 14. Maintain instructional documentation and training programs for customers, resellers, and integrators. (done or partially done)

Thanks for your feedback. My merchant account allows me to accept debit cards that most gateways like PayPal don't support. I only pay 50 cents per transaction on these debit cards, and almost everyone uses them here, so it's very important for me that I'm able to offer this type of payment. However, I'm currently paying a monthly non-compliance fee to my acquirer, so while it's an old thread, this is a current issue for me, and I thought it made more sense to post here than to open a new thread. I would find it very interesting to know how other WHMCS get around the issue, but it would also be great if WHMCS could give an update. By now, Phase 5 is in effect, so all merchants should now be required to be PCI-DSS compliant, and fines are very hefty.

The PCI vulnerability scan is only a tiny fraction of PCI compliance, and IMO the easiest hurdle to cross. WHMCS obviously have some kind of development process, change control procedures, etc. As long as these procedures are in line with PA-DSS, I'm not sure if the applications actually have to be formally validated. According to VISA: While the use of PA-DSS validated payment applications is recommended, a payment application need not be included on Visa’s list of PABP validated payment applications or PCI SSC’s list of PA-DSS validated payment applications in order to comply with Phase 2, Phase 3 and Phase 5 requirements for use of PA-DSS compliant applications. Acquirers may determine the PA-DSS compliancy of a payment application through alternate validation processes, which should confirm that payment applications meet PA-DSS requirements and should facilitate compliance with the PCI DSS. However, the points I mentioned relate directly to the SAQ that merchants need to fill out if they are transmitting credit card data through their systems. They are fairly simple to implement, except maybe the two-factor authentication, which might require some more thought and work, but without these implementations, I just don't understand how any merchant using WHMCS can become PCI compliant, unless they only accept CC data over the phone.

From what I can tell, WHMCS is not PCI compliant out of the box. One example is non-consumer users' passwords. PCI compliance, from what I understand, requires payment applications to adhere to following items: - Non-consumer user and administrator (admin) passwords must be strong nad contain a mixture of alphanumeric characters - Admin passwords must expire every 90 days - Admin passwords cannot be the same as the 4 previously used passwords on the same account - Admin passwords must be changed - Two-factor authentication requires that two of the three authentication methods (see PCI DSS Requirement 8.2 for descriptions of authentication methods) be used for authentication - First-time and reset passwords must be changed immediately after the first use - Minimum password length of at least seven characters required - Repeated access attempts limited by locking out the user ID after no more than six attempts - Once a user account is locked out, the lockout duration is set to a minimum of 30 minutes or until administrator enables the user ID - If a session has been idle for more than 15 minutes, users are required to re-authenticate Unless I'm overlooking something, WHMCS doesn't seem to handle the above, so I'm wondering where that leaves merchants using WHMCS to process card transactions. These are all required even if no card data is stored in WHMCS, as far as I know. It is part of the SAQ-D. How do the other WHMCS owners handle these issues?

Here's another way to do it - in your stylesheet, add the following: div[style="position:absolute;top:0px;right:0px;padding:5px;background-color:#000066;font-family:Tahoma;font-size:11px;color:#ffffff"] { background-color: #c08121 !important; /* Change bg color */ position: fixed !important; /* Change positioning */ /* etc. */ } Here's how to add the line break: div[style="position:absolute;top:0px;right:0px;padding:5px;background-color:#000066;font-family:Tahoma;font-size:11px;color:#ffffff"] a { display: block; }

I agree. This should be editable. At the very least, the "admin bar" should have an ID assigned to it so that the styles can be overriden. At the moment, it's affecting my customised theme. I know I could use javascript, but why make it so difficult?

I think that applies for storing PANs, and other sensitive data, not the CVV code. If you store the PAN on your servers, then you'll need to complete the SAQ-D questionnaire, which, as far as I know, is the most lengthy one.

I'm not fully clear on the regulations on storing CVV numbers. Are you sure that CVV numbers cannot be stored at ALL, or could it be that they can be stored only until the card is authorised? If you look at the Visa guidelines, you'll see the following: "In certain markets, CVV2 is required to be present for all card-absent transactions." My merchant bank charges a fee for all transatctions entered without a CVV number.

Yes, md5 is one way, so once the password is stored, it cannot easily be decrytped. This is what I'm using to check if user's password is correct when they log in to my other system (already existing clients as well as WHMCS clients can now log in): $enc_password = $data['password']; $salt = substr($enc_password,-5,5); if ( md5($salt.$entered_password).":$salt" !== $enc_password ) { return false; } else { // do login }

Just figured it out. Couldn't find it before, but the salt used to encrypt the passwords is attached to the end of the password. This is the format: md5($salt.$password):$salt

If we can't decrypt the passwords, we should at least be able to encrypt them. Otherwise how would we check the entered password against the one that's stored in the WHMCS database?

I know this is an old thread, but I came across it when looking for information on how to select countries you want to sell to using WHMCS (or countries you don't want to trade with). Is this possible in WHMCS? Regarding the last post: maybe here (for U.S. companies): http://www.treas.gov/offices/enforcement/ofac/programs/

Hi! I'm wondering if it's possible to allow users to download their PDF invoices through another system without that user having to log into the WHMCS client area? Perhaps by supplying an admin or api username and password in the query string. For example: whmcs/dl.php?type=i&id=1&username=admin&password=AdminPswd