Jump to content

Cody

Blesta Developers
  • Posts

    1,574
  • Joined

  • Last visited

  • Days Won

    74

Posts posted by Cody

  1. I like the consistency, but these might be a problem due to the simple fact that the buttons don't mention "PayPal" in any capacity.

     

    Personally (and this is me speaking as an individual and not in any official capacity as a Blesta dev), I like the idea of not using graphical buttons at all. I think they should just be regular UI buttons that say either "Pay with PayPal" or "Pay with PayPal Subscription". And similarly for all other non-merchant gateways (i.e. "Pay with Payza", "Pay with Skrill", etc.). That would be, by far, the most consistent implementation, and the most graphically pleasing.

     

    On a side note, PayPal has some of the ugliest buttons ever imagined. They were ugly in 1998, and even more so today. This only fuels my desire to do away with graphical buttons altogether.

  2. All I did was change the URLs to the images in /components/gateways/nonmerchant/paypal_payments_standard/views/default/process.pdt. Would Blesta consider making these buttons standard please, as my alternative PayPal buttons are neater and more helpful to users?  :)

     

    I like the consistency, but these might be a problem due to the simple fact that the buttons don't mention "PayPal" in any capacity.

     

    Personally (and this is me speaking as an individual and not in any official capacity as a Blesta dev), I like the idea of not using graphical buttons at all. I think they should just be regular UI buttons that say either "Pay with PayPal" or "Pay with PayPal Subscription". And similarly for all other non-merchant gateways (i.e. "Pay with Stripe", "Pay with Skrill", etc.). That would be, by far, the most consistent implementation, and the most graphically pleasing.

     

    On a side note, PayPal has some of the ugliest buttons ever imagined. They were ugly in 1998, and even more so today. This only fuels my desire to do away with graphical buttons altogether.

  3. In theory you could store the private key in the database and that would be just as secure as storing the password there. (Assuming it is encrypted) 

    My ssh is already locked down to known ip's via firewall and my backup user is very locked down as to what they can do anyways.

     

    Yeah, but I'm just trying to highlight that this doesn't really add any additional security to clarify for those that may be under the impression that Blesta will magically read their PGP key-ring or something. That said, using asymetric keys is preferable to passwords for requesting shell access so I guess CORE-1272 is a net positive.

  4. Such a feature would require a lot more verification than just a staff email from address, as that would be trivial to spoof, and my guess is you wouldn't want random viruses appearing in your client's documents section.

     

    Something like this would require you to use signed email messages. This means you'd need to use PGP message signing for the email you send, which would then need to be verified by the web server when it's received to ensure the content of the message really did come from you, and that is hasn't been altered when in transit.

  5. Have we abandoned this topic already? I'm not here to blame anyone, point fingers, or none of that!

     

    I'd just like to see either the stripe.js method as an available option or at least discuss and address the reasons why it won't / can't be?

     

    Should this be pursued as a 3rd party add on option? Let me know!

     

    Why are we still talking about this? As I've already said, it's in the worksCORE-1085.

     

    /thread.

  6. The order form url is like this :   domain.com/client/index.php/order/main/packages/OpenVZ/?group_id=1

    When hovering over the order link in the portal the link looks like this : domain.com/client/index.php/order/

    Clicking said link brings me here : domain.com/client/index.php/404/

     

    Client is the blesta root and OpenVZ is the order form Name and label. 

     

    I need the actual URL, so I can visit your site and see where it's redirecting.

  7. I've tried that many times with the same result.  I read through the CORE-1246 bug report and tried creating the order form with out making any edits to it before setting as default, still no go. I have reinstalled blesta(more than once,lol), cleared the cache, tried recreating the order forms and setting the default, none of it works for this issue unfortunately. All other links from the portal work fine

    What's the URL to the order form you're trying to set as default?

  8. So, is there a work around for this issue currently? Without an order form, my monthly blesta license is kinda useless to me, lol.

     

    If you're experiencing an issue related to CORE-1246 then all you need to do is go to [Packages] > [Order Forms] > [settings] and select the default order form and click save.

  9. 2.  As for an attacker altering the JavaScript, this depends.  If you load it directly from Stripe's servers then data theft would be more of a risk if the file gets modified from Stripe's end (but at that point your worries are more than just a modified JavaScript file...).  That is one of the reasons why its not suggested to load those files locally.  However, JavaScript is one of those easily-hacked technologies if you know the right techniques.

     

    This is completely irrelevant. If the CC number field is sent by your webserver, it can be compromised regardless of where you load stripe.js from if your server is vulnerable.

    The point Paul is making is that your webserver is serving content to the client for a page that requests credit card information. As long as that is the case you are at risk if your server is vulnerable. This is why it is inevitable that stripe.js and other work-arounds will be squashed by PCI compliance.

  10. To Clarify:

    I have this checked. Yet, Blesta still lets clients set up a Payment Account and store their credit card information. This information is not stored on my server? Stripe saves that for me, so I can then bill them later, correct? Therefore, none of the credit card data is stored on my server?

     

    Blesta will not store the card number in that case. Blesta has to store some card information, though. This includes the card type, last 4 of the card, and expiration date. This is required so that Blesta can send card expiration notices to clients, identify the card to the user for proper selection, and process refunds and voids.

  11. Can someone confirm whether these statements on the matter is correct please?

    1. Blesta's Stripe Gateway will currently send through the card details to the Stripe server but will not store them locally.

    If you check "Store Card Information Offsite" when configuring Strip in Blesta, Blesta will not store card details locally.

     

    2. If I have a SSL certificate on my Blesta install the card details are encrypted when they are submitted and sent to Blesta.

    You must enforce the HTTPS protocol. An SSL cert itself is useless if you're not forcing people to use it. See Forcing HTTPS in the User Manual.

     

    3. This means my customers are safe and I am safe from potential legal fines.

    You still need to perform PCI compliance scans if you accept credit card payments. The only way you can get around that is if you only use non-merchant gateways (paypal, skrill, etc.).

×
×
  • Create New...