Max

The PACKAGE the service is using, was created as a brand new package in Blesta? It was not perhaps imported from WHMCS or created in any other non-standard way? And it shows it is tied to a "NOC-PS management server" in the package settings, like below? Also try editing and saving the package settings just in case.

What gateway are you using now?

Note that you already set the HttpOnly flag, so it is not possible for an attacker to steal the cookie through any Javascript injection vulnerability anyway. Which is good. If you did not have that flag, the IP restriction could be used as an alternative protection against that. However, this thread is about the Secure flag, and I do not think your IP restriction helps at all for situations that flag is actually for. Which are situations in which the attacker can actually capture and manipulate your traffic... Imagine the following situation: You are using the Internet at a public location, e.g. at a conference, using a public wifi access point. You are logged into Blesta using SSL. It displays the padlock icon and everything, so you think it is safe. Now what could possibly go wrong with that? Well, if I were the rogue wifi access point operator, your laptop is connected to, and you happen to visit any random other (non-SSL) site during the same session (or a website controlled by me), I could inject <img src="http://your-blesta-server/" width=0 height=0> in your traffic. Causing the cookie to be sent in the clear, and intercept that. Even if your webserver is configured to automatically redirect users requesting http to https, your browser will still send all cookies set previously for that site in the clear first as part of the http request, before it is being redirected. And since you are using MY connection, using MY IP, the IP restriction will not do any good. I can send requests using my own IP too, you know... When a Blesta user accesses the site through SSL it really should set the Secure flag when setting any cookies, so the browser knows it is to only allowed to send the cookies with https requests. It also should regenerate the session id number and invalidate the old one, if the user did access Blesta through insecure HTTP before that point.

Double check you do not have a } too many, or a { too little somewhere in the code above that line.

Haven't tested it with newer releases, although I would expect it to work. Are you having any problems with it? We're currently not actually using Blesta ourselves, but still our custom developed billing system, we would like to replace one day. This was more a proof of concept to see how easy it was to modify Blesta for some of our needs. Not making any commitment to update it. Open up a feature request for an official replacement if the functionality is critical for your business.

It is only allowed to display pricing excluding VAT if you sell to business customers. E.g. store chains like METRO/MAKRO that require you to register as a business customer, and require that you swipe your membership card to enter the store, do can display prices without VAT. But at any normal supermarket, the price displayed is exactly what you pay at the cashier. Same online. It is fine to display pricing excluding VAT for professional business services, like website design at an hourly rate. Or a datacenter selling $ 500/month dedicated servers. And yes, we also display pricing without VAT for software products for professional customers. But it is not very credible to claim that hosting companies advertising $ 5 domains and webhosting are not targetting consumers. If you sell to consumers, prices need to include VAT, period.

In addition to Vmware, the module supports Proxmox, Xenserver and oVirt (aka Red Hat Enterprise Virtualization) VPSes as well. We do not offer Windows to customers ourselves though, so don't know which one works with that best.

You already had to retain some evidence about the customer's country before. E.g. to be able to exempt your American customers from EU VAT. So that is not much new. As brought up before, what is far more important is that Blesta is modified so that the information on invoices cannot be changed after the invoice is issued. If the customer changes his country in the client settings, it shouldn't change the address shown on existing invoices. The likelihood that a tax inspector notices that the country shown there, suddenly no longer matches the VAT percentage, is far more likely than that a tax inspector cross checks the customer entered country by IP-address... A problem does is that if you are selling to consumers (not b2b) you are legally required to show tax inclusive prices on your website, price lists and any advertising material here. You are not allowed to require a customer to jump through hoops and sign-up first, before he can see final pricing. So either need a simple way for the customer to select his country from a dropdown before hand (or auto-detect it with geoip) and show the correct pricing in the shopping cart and elsewhere. Or need to use the same tax inclusive prices for all countries, and absorb any VAT rate differences yourself.

Technically you can. However do note that you are not allowed to sell vpses with the free edition of ESXi, and Vmware's commercial licensing is pricey.

It indicates that servers in the foreign 1.2.3.0/24 subnet are attached directly to the eth0 network. So that it knows that if it wants to speak to say 1.2.3.10, it can send an ARP request for the IP 1.2.3.10 to get the MAC address of the server, and then send traffic directly to the MAC address of the server. If you do not tell it that, it will indeed also send it through eth0, but it will then be covered by a slightly different route rule among the lines of "ip route add default via 4.5.6.1 dev eth0" which will address all foreign traffic to the MAC-address of the default gateway 4.5.6.1 to be routed. So the traffic flows through eth0, through your switch, to the uplink switch port to your provider, to their the router, back to your switch, to the other server. Depending on the accounting method used by your provider this may indeed cause it to be charged, and probably even twice, as both upload and download traffic. So you either need to setup static routes to give a hint to your servers that the servers in the other subnet are local and there is no need to send the traffic to the address of the gateway. Or you need to let your L3 switch do the routing. In that case you would need to configure your switch properly, and change the network configuration of all your servers, so that the default gateway IP in the server's configuration would be of your own L3 switch, instead of your provider's.

L3 switch = router. That said, you do not have to use it as such. If you prefer not to mess with your switch, and do not have any VLANs configured, you can also just configure device 1 and device 2 to use static routing and talk to each other directly, instead of letting communication go through the default gateway IP-address provided by your provider which is happening right now. Assuming device runs Linux: "ip route add 1.2.3.0/24 dev eth0" where 1.2.3.0/24 is the subnet of the other device.

Correct. Uses public key cryptography with separate keys for each site. When the user registers on an u2f capable website the token generates a fresh public/private key pair, and sends the public key to the website, along with a key id. Upon logging in to the website, the user first enters its username and password as normal. The website then sends the key id corresponding to the user and a challenge to the token, and -after the user press the button on the token- the token uses the corresponding private key to sign the challenge. In most implementations the key id is actually not really an id, but actually the entire private key encrypted by the token, so that the token does not need storage space for dozens of keys, just for the key used to encrypt/decrypt the private keys. The u2f standard also has some other clever features like that it restricts keys to a domain, so that if the user was tricked into logging in to a phishing site, the token will not function properly. There are currently some downsides as well. One is that U2F tokens require two way communication and therefore need browser support. Only Google Chrome supports them for now. This is unlike traditional Yubikey tokens which emulate a normal USB keyboard and therefore work with any browser and can be used in other things than browsers as well (e.g. to restrict SSH and VPN access).

Sure. But is there any payment service provider out there that doesn't mention it in the small print?

FIDO U2F is a new standard for 2 factor authentication USB tokens. https://fidoalliance.org/specifications/download http://googleonlinesecurity.blogspot.nl/2014/10/strengthening-2-step-verification-with.html https://github.com/Yubico/php-u2flib-server Main advantages over OATH/Yubikey: Can use a single token with multiple websites without central authentication servers, because it uses public key cryptography instead of shared secrets. Cheap enough to hand out to customers. Tokens start at $ 5.99 (versus $ 20 for a classical Yubikey): https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=FIDO%20U2F%20Security%20Key

For non-merchant redirection gateways such as Paypal standard, where the users sees www.paypal.com in the address bar, instead of your site URL, there is no need for PCI compliance. That's why non-merchant gateways are a much better option for most businesses. For every gateway that allows payment information to be collected while your own site URL is in the address bar -including Stripe- you need PCI compliance when PCI 3.0 becomes required (2015?) Do note that Mastercard and VISA do not require compliance VALIDATION by the acquiring bank for smaller merchants. This means that while you do need to comply, the gateway/bank is not required to check that you actually ticked all the boxes on the SAQ paperwork, and actually did the quarterly external security scans. It may therefore still be tempting to "forget" to comply. However if there is an incident, they likely do want to see it, and if it turns out you were not in compliance, there will be trouble. That they didn't check up on you earlier, does not mean the contract clause requiring compliance will not stand.

Ah, I misunderstood. I thought that with "cash deposits" you meant you used a prepaid "pay-as-go" billing scheme, where customers have to add funds first, and every order is deducted from the balance. Yes, sending an invoice for the non-refundable retainer fee first, and a second final invoice that has two line items: one for the entire amount, and a negative one that deducts the retainer, is common.

Problem is that the moment you write out an invoice, you are indicating that you performed a service to the customer. This also has the consequence that you owe the government tax over the amount on the invoice. It is generally better to postpone tax liability, until the moment you actually do provide the service. What if the customer makes a prepayment for $ 1000 today (2014), you write an invoice for $ 1000, but the customer does not spent the balance straight away, but waits until 2015 to order a long list of domains? Let's disregard sales tax for simplicity, and only look at income/corporation tax. $ 1000 turnover - $ 0 costs = $ 1000 profit in 2014 to pay income tax over. But you'll end up with a lot less than $ 1000 after you paid for the domains the customer will order in 2015... Rather pay nothing in 2014 yet, and the amount actually earned in 2015.

Wouldn't it be better to open a feature request for a receipt then? E.g. the domain registrar we outsource our international domain registrations to, uses a prepayment system as well, and sends: an e-mail notification when an incoming payment is received. Listing amount received and how it is applied to our account. (in our case the e-mail also mentions the conversion rate, as we send money by bank transfer in EUR, and they convert it to USD at the official ECB rate for us, avoiding bank commission) once a month: a normal VAT invoice for services actually rendered. once a month: an account statement listing payments and invoice(s) that month, and the remaining balance left. An invoice and an account statement are different documents, with different tax implications (at least when using accrual accounting)

Would personally not write out an invoice for things like cash deposits. If you work with prepaid balances, using account statements may be more proper. But can think of other situations where categorizing invoice line items could be useful. If you sell other stuff than just hosting, there may be accounting requirements that requires categorizing. E.g. here we need to report our turnover for "goods exported to other EU countries" and "services sold to customers in other EU countries" separately. So need to know if the line item is a good or a service.

Running Plesk on the same server as Blesta is known to be broken. Was already reported by me before, but think the thread got deleted, because it was in the beta forum of a previous Blesta version. Creating a client only adds the customer to Plesk's database, it doesn't affect webserver configuration, so that works without webserver restart. Once you do any chance that adds or updates a website it does restart it. Note that the Plesk admin webinterface/API server itself does not run under Apache, is not restarted, and sends a proper reply back, however since Blesta is killed it cannot process the response.

Is Blesta hosted on the same Plesk server? Has been reported before that that doesn't work. Plesk restarts the webserver and kills all running PHP processes -including the Blesta one- the moment you add or update any webhosting account. Also concerns the same server that is hosting Blesta? If it concerns multiple modules, Blesta should be changed to provision hosting packages asynchronously. (from cron, or by spawning a separate process that calls setsid() first so it doesn't belong to the same session as the webserver, and then performs the actions in the background)

There are also other reasons than non-payment for which you need to be able to write out credit notes, and pro-forma does not help with those. E.g. when a customer returns goods to your store, or for any other reason that warrants a refund. === Here you do are allowed to use the regular "tax invoice" template, and maintain the normal invoice numbering. Only need to put negative quantities and negative total on the invoice, and add a note saying it is a credit note, correcting invoice # 123 dated $date. Problem is that Blesta doesn't accept negative quantities by default though (got rid of that verification rule in my patch, along with adding a "void and create credit note" button).

Personally, I think just storing all fields de-normalized in the invoice table (for generating reports), in addition to .pdf caching and an option to mass-download the .pdfs (for invoice retention), is the most practicable method. Whatever method you choose, keep in mind that the invoices must be retained long term. That doesn't necessarily mean they have to stay in Blesta long term, but if not, they must be easy to transfer over to your computer to store locally. In that case viewing older invoices that have been transferred and removed from Blesta, must be disabled, and not allow the user to generate a new pdf. By reading things like "Option to delete archived copy after X months" I think you may not have a clear idea about the actual legal non-negotiable requirements yet. Most EU countries require around 7 years of retention for the actual invoices sent and received, see page 19 on: European Retention Periods.pdf If this is a problem due to the size of Blesta's PDFs, than the first priority would be to reduce those, not embedding the unicode font in the pdf when no non-ASCII characters are used. Other customer records (page 25) have a shorter retention period. E.g. you are supposed to delete the personal details of an inactive customer from your system within 2 years here (although that often does not happen in practice). Storing customer data at Amazon AWS -or any other US company or hoster- like suggested in CORE-923 is problematic for EU companies. First there are privacy laws that restrict the processing of personal data outside the EU. In short the company you are storing the data at must guarantee they comply with the EU rules (are on the EU-US safe harbour list), and you may have to inform your customers that you are shipping their data there... Second some countries have laws requiring accounting data to be stored within their jurisdiction for enforcement reasons. They do not like the idea of you being able to claim that you stored your accounting data on some vague cloud service in the other end of the world, and that it happens to be down, the moment the tax inspector pays a surprise visit...

>my suggestion is to make the final invoice a stored pdf invoice in webhost , or add array info as paulov suggested . PDF caching alone is not good enough, also need the information on the invoice easily accessible in the database for taxation purposes. Need to know the country and VAT number of the customer as it was on the day the invoice was issued at a minimum.

Yeah, think you are right. SAQ A-EP is only for direct POST and stripe.js like integrations. Most people using those didn't bother to comply with any PCI requirement, and might be in for a shock once they have to comply with 3.0. From a quick look, some of the requirements include: - Everyone needs separate webserver, database server and DNS servers(!) - SSL for everything - Two-factor authentication for VPN access to your management network Also has some requirements I think are stupid, like locking accounts after 6 failed attempts. So if somebody tries to log in 6 times on my account, which they wouldn't succeed in thanks to strong password, I shouldn't be able to login as well?