velaware
-
Posts
346 -
Joined
-
Last visited
-
Days Won
8
Posts posted by velaware
-
-
So I didn't even realize that they dropped server federation last year. XMPP client-to-server is still supported but I'm guessing that doesn't help us here. Glad to see Google staying true to their "openness" mantra.
One of the reasons I've moved away from Google and only use it for forum accounts and junk stuff now. I use Outlook.com and as I say to others, its not a Windows vs. Linux thing, its a usability vs. breakability thing.
-
My database isn't big enough to notice a different between MySQL and MariaDB. They were both about the same speedwise.
Does MariaDB use less resources compared to MySQL that you can find out?
-
They have fixed the one issue I've experienced with MariaDB. All is well in MariaDB land
Notice any performance improvements?
-
Does the public and private key change at all or are they created once and that's it?
-
You are right that being PCI compliant is the user's responsibility, and not Blesta though.
It is Blesta's responsibility to the degree of what it can do. Blesta isn't responsible for having proper accounts/software installed and configured, but it is responsible for how it stores and handle CC data.
-
Maybe you can clarify PCI levels.
I understand PCI Level 1, 2, 3, 4 to be largely based on transaction volume. See http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp. Levels 2-4 require the annual SAQ and quarterly network scan. Is this what you mean?
If you are a Level 4 merchant, based on your transaction volume, you still have to fill out the SAQ, and get a quarterly network scan.
I think the question is, what exactly is the difference in terms of what you have to do by using stripe.js versus passing the data through without storage. If all merchants must fill out the SAQ, and get a quarterly network scan for PCI compliance, and using stripe.js does not exempt you from these requirements, what is the difference?
I know PCI level 1 is more towards those who do 4 mil. + transactions, not sure on the others as I'm not a banker or someone heavily involved in it. I've never been aware of a transaction class for them, though, just more so what you intend to do with the data.
What Stripe.js does is send the card data directly from the browser to Stripe's servers, without the server Blesta is installed on ever seeing that. It then returns a token/hash of the data that Blesta can store in the database without ever knowing what the card data is. This is why Stripe created the JS library, so that it's client->server instead of client->server->server. From my previous experience, once any bit of card data (last 4, cvv, etc...) touches the server that Blesta is on, it has to conform to PCI regulations, because its still sensitive information.
Blesta still stores some data. IF the data is encrypted, then it helps tremendously, but that requires that the last 4, cvv, address, etc...(whatever it stores) is encrypted. But, with how Blesta works now, that data in its completeness is still passed to Blesta, which means now the user has to at least conform to level 4 or 3.
Yes, network scans and such are still required even at level 4, though they are not as intrusive so to speak (takes a lot less to do than say a level 1 scan).
The whole argument here, and what has I believe been presented before, is that Blesta sees the card data (full PAN, CVV, etc...). Even if Blesta doesn't store it all, it still stores some and thus needs to comply with PCI. Using something like Stripe.js changes that so Blesta doesn't have to concern itself with meeting PCI and it can just store a token that it can then pass to Stripe and Stripe can map it to card data.
Basically any servers that see card data need to comply to PCI. A token isn't card data. You can still retrieve the last 4 and all that via the token. It just takes an API call.
-
I predict that in the future, stripe.js and other javascript implementations will no longer be exempt from PCI. While the card details technically don't touch the server, the server is responsible for serving the markup. An attacker with access to the server could modify the javascript in order to intercept those details.
The whole purpose of Stripe.js and such is to allow users to store card data without having to meet PCI level 1 & 2 compliance, not to do PCI avoidance. It lets you offload the storage security requirements and worry about managing your systems.
https://www.pcisecuritystandards.org/documents/SAQ_D_v3_ServiceProvider.pdf document page 17 (real page 23) starts the questionaire portion of data retention and storage. This document provides the bare minimum required to be PCI compliant (level 4).
The JavaScript libraries aren't really exempt from PCI, its just that they allow the provider to meet PCI requirements without having to follow level 1 & 2 guidelines themselves, and it also makes meeting level 3 & 4 a lot easier as well. Which, poses another risk, but its one people take regardless.
-
I'm certainly keeping a very close eye on this thread..
I have been using stripe so I'm not very sure what to do now. I, like everyone else didn't realize tokenized transmission wasn't supported.
It is and isn't.
Blesta's Stripe module tokenizes data, but it doesn't do it in a fashion that it should so people are compliant w/t PCI level 3 & 4 (which requires that no card data whatsoever is to touch the server). This is why the JavaScript libraries are made by such providers, so that people can write code with JavaScript (which runs in the browser thus never having to touch the server) to tokenize data, and then the JavaScript just sends the tokenized data to the server.
Blesta's Stripe sends the card data to the Stripe's server which then tokenizes it on their end. So, the whole "don't let Blesta store card data and instead let Stripe store it" feature works and is accurate, because you don't store the card data in Blesta's database, but it doesn't solve the PCI compliance issue because you're still directly sending card data to the server Blesta is on. That's the point I was trying to make to Cody but I was also cooking dinner so I may have not got that across properly.
-
This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.
Just to clarify, you're saying having card data be passed through Blesta (which is stored on a seller's server) doesn't violate PCI even if the data isn't stored?
Not trying to be a dick, just wanting to verify/clarify this.
-
There probably should be something in the documentation to indicate which API it implements. I don't understand what you mean by "isn't fully tokenized" though. Blesta does not at any point store sensitive card details for Stripe, just the token. (Unless configured to do so instead of tokens). The contention is the pass-through of card details. It's still tokenized, it just isn't using stripe.js to keep your server from seeing those details when the payment account is initially created.
The result is that Stripe works a lot like Authorize'net's CIM method. As far as I know, there is no stripe.js equivalent to Authorize.net CIM. There's less risk than storing card details, but some risk because of pass-through, and a requirement for PCI.
The problem with this though is that it violates PCI, since card data still has to enter the server to be tokenized and sent to Stripe. That's the whole issue. That's the whole point behind the JS library being provided, so that it only passes from the client to Stripe's servers, not client->my server->Stripe's server.
-
Stripe is a merchant gateway and does not work like PayPal at all, so it's not possible. A payment account exists in Blesta, and Blesta makes the necessary API calls to Stripe when it wants to charge a card (and passes the token). Allowing Stripe to inject javascript code in the process means that a feature is necessary by which all merchant gateways could do the same.
Didn't know the Checkout thing required the JS library still. I do know some merchants have offered a non-merchant style payment method too.
Why not have the module gain access to the JavaScript helper like widgets and such have?
-
Thanks for this - I appreciate your expertise and am interested to see what Cody says about it.
No problem, feel free to contact me any time on this.
We've been looking into ways of providing gateways the ability to inject javascript into the payment process for some time. It's coming down the pipeline but to be honest, unless there's more of a demand for it, it's not happening in 3.2 or 3.3.
Can't it be possible to at least support the Stripe Checkout, which acts like PayPal's non-merchant systems as well?
-
Hi there,
Thanks for that, though I'm not entirely sure I understand. As I see it, using stripe.js or Stripe Checkout, and never handling the credit card details (they are shipped off direct from the user) as well as serving payment pages over SSL makes you sufficiently compliant (source: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do)
You're correct. The problem is that the current way Blesta works, it doesn't let you use the stripe.js file. While I can't comment on Stripe Checkout, I'll forward this thread to Cody so he can shed some light on this. If such features can work, then it'll solve my issue as well.
I was looking at Blesta as a competitor for WHMCS, which is fully compatible with the above setup (albeit by plugin) and as a result is fully compliant with all the questions Stripe ask. Blesta merrily advertises itself as Stripe compatible but does not state that you actually deal with card numbers. I assume this is what requires the PCI compliance above. Similarly, if I didn't realise after a lot of research (I had to deconstruct the payment form before it became obvious to me), how many other users are there out there blindly thinking they are using fully tokenised storage and transmission (and attesting this to Stripe) when they are actually handling card numbers - surely there should be a clear warning to them on the site docs, at the very least? Blesta is very easy to setup and its even easier to get Stripe working with it- most wouldn't even check.
I can't say anything on how Blesta handles things, but I do agree a warning and such should be stated that the current module requires PCI-B or A compliance (since the fee for not being compliant is very high [$50-100k USD]).
-
Hi,
Thanks for that. I'm very interested in the requirements for PCI compliance - the Blesta website does not at all make it clear that it doesn't support Stripe in a fully tokenised manner - this is the default selection on the Stripe website and there is no relevant documentation from Blesta, so I'm sure I'm not the only person who was caught by this.
What would I have to do in order to make Blesta compliant? I thought PCI compliance was relatively unattainable for small businesses, that's why companies like WorldPay and Barclaycard ePDQ have such domination over the UK payments market?
PCI compliance, depending on the level of compliance you need/want, is pretty easy.
I can't talk about WorldPay or ePDQ because I don't know them or anything, and I don't want to provide false information.
To be PCI compliant currently, the best way to describe it is to have Blesta's database be on a separate server that is not accessible outside of a local Intranet and stripped down to the absolute necessaries. PCI level B would be the minimum I'd say due to the lax that C still allows that puts your user's information at risk. PCI level A is fine, but is more so if you handle a lot of transactions a day (4 mil. +).
If you would like consultation for this I'm happy to assist. This is one of those things that a lot of people don't think about until its too late, so you looking into this now is very wise.
-
I've been testing out the Stripe gateway, and unlike most others I've seen, it looks (from the code) like the credit card details are communicated to the server and then onto Stripe - is this true?
If so, is there any way to implement it so the details go directly to Stripe, as with a WHMCS-style Stripe plugin? And if not, what are the PCI implications of having the credit card numbers touch your server as the client pays?
Thanks!
I've talked to Cody on this about a similar service (Balanced Payments).
Right now the way the plugin works, it requires your server(s) to be PCI compliant because it stores sensitive card data. Though, i have suggested that gateways have the ability to inject HTML into the order form so things like Stripe's javascript can be included which changes the PCI requirement from A/B to C/D, which would make it far more viable for those who want the features of Stripe and similar.
If you keep the card info, like you have to now, then you have to follow the QSA guidelines set in by PCI. If you're interested in learning more, feel free to contact me. I used to work for a hosting company who performed these tests all the time and I can offer some guidance. Either ask here (preferably so information can be shared to others) or PM me.
-
I just did a fresh install of Blesta and set everything up including the cron job. Everything was great until right now. I was logged out of Blesta admin and now can't get back in ("No matches found for that user/password combination."). I can still log in to the client side, but cannot get into the admin side. The last thing I changed was the timezone from Denver to Eastern Time. I don't know if that had anything to do with it. I went into PHPMyAdmin and changed it back to America/Denver, but that didn't fix it. This is actually the third fresh install I have done trying to fix this issue. I've had Blesta running on this same server for over a year and everything has been great until I went to upgrade to 3.1.1 and accidentally downloaded all of Blesta and not the patch and overwrote files... So I thought I would do a fresh install and now this is happening.
I greatly appreciate any help I can get. Thank you for your help!
Does this query:
SELECT * FROM `staff` LEFT JOIN `users` ON `users`.`id`=`staff`.`user_id`;
Return anything? If so, try doing a "reset password" if you set up the mail server info (if needed).
-
Looks fine for me when I try it bud.
What did you try, exactly?
-
You might have to save and edit in source mode only. We spent a lot of time considering different WYSIWYG editors that are license friendly, and it was the best, but they all seem to have some problems.
Happens then too. :/
Thought I made it clear but I didn't, my bad. o.O
-
Blesta can't log everything it does, but it would certainly be nice to have an option that may be temporarily enabled to provide additional logging. This has already been discussed numerous times, and our answer is still the same. We can't provide verbose logging until we can make PHP 5.3 the minimum requirement for Blesta.
With that said, however, if there is something in particular you'd like help debugging we can certainly walk you through that.
My question is what makes 5.3 special for this? I'm not familiar w/ the changes, but if its a function you could just do
if(function_exists('some_func')){ .. verbose logging stuff ... } -
I need to know exactly what is happening when the support managing pulls tickets from the POP3 server.
If you want me to help you on this feel free to shoot me an email.
-
This doesn't work for me.
My Blesta install is a subdirectory (http://www...com/accounts/) and even when I fix that (i.e.: URL is https://www.....com/accounts/plugins/live_chat/vendors/blc/index.php/site_admin/ ) I get a blank page (enabling display_errors gives this: Parse error: syntax error, unexpected '{' in /var/www/accounts/plugins/live_chat/vendors/blc/settings/settings.ini.php on line 76).
Fixing that gives this:
Cannot connect to database. If you are installing application please use /index.php/install/install url. If you keep getting this error please check that application can write to cache folder and cgi.fix_pathinfo = 1
When I visit /accounts/plugins/live_chat/vendors/blc/index.php/install/install I get this:
Make sure cache/cacheconfig is writable by applicationPlease advise.
-
-
Hello
Yes it does
In Blesta Admin, wen you click on "Live Chat" it will popup the Blesta Live Chat, then on Menu->Setings you will see an option called "Widget embed code", just click on it, and copy the javascript code to put in outer external pages even on static pages
Regards,
PV
Besides Blesta, anything else required to be installed?
-
I haven't installed it yet but curious, is there a way to get this to show on a regular website as well through JavaScript or is it just loadable on Blesta?
I don't have a dynamic website so doing something through PHP isn't viable for me.
[Plugin] Blesta Live Chat Rc 1.0.7 - 4ºrc
in The Marketplace
Posted
I don't know if they do or not, but the fact that Google will strip out needed/highly favored tech to push their own products kind of pushes me away from them.