Cody

Interesting. I found the Security Evaluation to be a good read. I wasn't aware that the token algorithm was published. Though I have some concerns with the use of AES-128, and most especially with ECB mode. Not to mention that the device key is only 6 bytes, and the remaining 10 bytes are quite easy to derive. So there is not much entropy in the non-encrypted token itself, though once encrypted it does appear to be sufficient for its purpose. The only question I have is how is the AES key computed? Hopefully it's not derived from the device key.

Your enom PASSWORD is the KEY.

This is something we've been thinking about for a while. Added CORE-923 to handle invoice caching. Will likely be in 3.2 or 3.3.

That's completely normal. It just means the time on your phone is slightly ahead of the time on your tablet. TOTP tokens are generated based on a given point in time and a pseudo-random key, the result of which is completely predictable if the key is known. That's not true. Yubkikey codes may be resused as well (there are only so many possible combinations). The way TOTP is implemented is you may only use a token once within a large block of time. This completely prevents man-in-the-middle attacks through token reuse. Yubikey is a pretty neat device, but I would caution against falling for the sales pitch that it's in any way better than a tried-and-true proven standard for multi-factor authentication such as TOTP. If anything it is less secure as the code used to generate the tokens is proprietary. When it comes to security, the general rule of thumb is if you can not verify the trustworthiness of the algorithm don't trust it.

What do you see in the logs under [Tools] > [Logs] > [Module], for the request? If it's blank per your screenshot then Blesta isn't getting the response from cPanel. It's an issue with your firewall or your server.

You can ignore that error. It just means one of the currencies it attempted to import already exists by default in 3.0. Everything else should have imported fine.

Sounds like a firewall issue. cPanel communicates over port 2087, so you're Blesta server or its firewall is likely blocking ingress from port 2087, or you have a mod security or some other software firewall blocking the types of responses sent from cPanel.

Just enter your enom login details.

What's the HTML version of your email look like? The issue is likely in there.

Not necessary in Blesta.

From the PayPal logs ([Tools] > [Logs] > [Gateway]) what is your 'business' and 'receiver_email' addresses? Also, what is your PayPal account address set to in Blesta?

Definitely feasible but nothing yet exists.

If the domain belongs to enom you can't add it in logicboxes. Use the enom module. If you're trying to transfer from enom to logicboxes create a domain order form and transfer through the order form.

Yes non-merchant gateways. Some gateways lock the ability to change the amount, others may not. But regardless, the user can generally change it to whatever they want simply by modifying the form contents as is the case with PayPal. That's an interesting concept and one I've never been able to fully understand (money is money, right? Gimme gimme), but I can recognize the need for it, legal or otherwise. The only problem I have with it is that it's simply isn't possible to enforce in the case of non-merchant gateways. Though I suppose if it is properly conveyed to the user then we'll get less "OMG this is broken, clients can may more than the invoice amount using PayPal!!!" false bug reports.

CORE-919 fixed for 3.0.7 ensures that the root web directory is treated as case-insensitive. Thanks for the report.

Already reported and fixed for 3.0.7.

That's the problem right there. See the article I linked in the manual in my last post. With a passphrase set you can only batch payments, or do manual one time payments.

You need to do a little more digging in the log. Specifically, you need the log output for the when the contact is attempted to be added. There is a lot of back-and-forth data logged when communicating with Logicboxes.

Hosting Package: {package.package} That's not a valid tag. Do you mean {package.name}?

When you decrypted the card did you use your login password or did you enter an encryption passphrase?

When payments originate from third-party sources Blesta doesn't have control over them. That's just the nature of the process. When Blesta constructs the form data that is sent to PayPal or any other nonmerchant gateway, it's (generally) treated more as a suggestion by the gateway that the user should pay the given amount. It's entirely possible that someone could submit payment to your PayPal account that gets sent to Blesta in an amount Blesta didn't suggest or expect. It's even possible for users to submit payment without ever visiting your Blesta installation. Now, that said, it would be possible to enforce through the interface that user pay the exact amount due on the invoice, but it would be misleading to suggest that Blesta could strictly enforce such a rule if accepting something other than credit card and ACH. I'm actually more interested in what UI improvements we can make to ensure that user's don't mistakenly pay more than they intend to. I'm curious how this happened as Blesta fills in the amount due by default.

Could you attach one of the reports? Feel free to redact any invoice or transaction lines. But we need to see what else is contained in the CSV.

Try: c:\path\to\blesta Note the lowercase "c".

That's not how it's designed. The text and the HTML tabs, as Tyson said, serve completely different purposes. Text is intended for text only, not HTML. Perhaps you're confusing HTML source with text. To edit the HTML source of the HTML content click the Source button in the WYSIWYG editor. Closing as not a bug.

I'm not sure it makes sense to enter gratuity as the payment amount. Blesta isn't set up to record and track gratiuity. I would imagine the best way to handle that would be to record the payment for the amount minus any gratuity, or create another invoice or line item to cover the gratuity.