Jump to content

furioussnail

Members
 View Profile  See their activity

  • Posts

    124

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by furioussnail

  2. 2checkout payments not recorded

    in Bugs

    Posted

    On 12/4/2018 at 2:44 AM, Tyson said:

    Blesta would log the 2Checkout IPN if it received one, but it sounds like it didn't receive one, or they didn't send one.

    I just tried to test this myself and I got a bizarre error page after submitting payment on 2Checkout's website. After submitting a payment, I'm redirected to an error page at 2checkout.com/checkout/purchase that shows the BoxBilling logo and displays an SQL error, SQLSTATE[HY000][2003] Can't connect to MySQL server on '...mysql.domain.com...' (111 "Connection Refused") that references our server's domain name for some reason. Do you receive an error when attempting to make a payment as well, or does it go through successfully? After payment, are you redirected back to Blesta?

    It looks like 2checkout went "full retard" and isn't a viable solution anymore. Not sure it even makes sense for you to invest development hours into this platform. They were acquired by Avangate and it looks like their platform acts as a billing panel. An horrible one. Now I am a bit desperate to find a good merchant payments processor. ? Thinking about Stripe Atlas but I am scared about the unknowns...

  5. 2checkout payments not recorded

    in Bugs

    Posted

    On 11/28/2018 at 8:47 PM, Paul said:

    Did you check the gateway log? Anything there? Tools > Logs > Gateway. Do you see a request in your HTTP logs from 2CO? Any errors in the logs? ../logs_blesta/

    There is nothing useful for 2checkout either in logs/ or in "Tools" -> "Logs" -> "Gateway". Absolutely no message. However, I didn't even configure INS since there is nothing in the documentation on how to do that.

    Thank you.

  6. Accepted Payment Types

    in Support

    Posted

    On 8/29/2018 at 6:52 PM, Paul said:

    What option should you select when? When "Recording Payment" - manually adding a transaction as an admin? You can select whichever option makes sense. IF you have 2checkout and PayPal installed though, the customer should be able to make payment with those methods and the transaction be applied automatically to their account. In that case, there's no need for you to select either.

    2checkout and PayPal are both non-merchant gateways, meaning the user can pay with them by name. They leave Blesta to complete payment, and then return. CC & ACH options are intended to work with merchant gateways like Authorize.net, Stripe, and others where the customer completes the payment all within Blesta.

    2checkout doesn't actually apply transactions automatically. I created a forum topic regarding this issue but got no reply: 

     

  8. theme.css?dir= uncacheable

    in Support

    Posted

    17 hours ago, Paul said:

    I don't know the reason ?dir= is appended to the file. I'll bring it up with the team. What kind of caching are you doing, and how is the resource interpreted? Does it assume that it's a dynamic resource, and does not cache it, or? If it was cached, a new theme would not be picked up until the cache expires. For the admin area, this is a problem if you have multiple companies and are switching between them. The URL would stay the same, but the company & theme would change.

    Perhaps the file name should be THEMENAME.css

    Yes, I think the theme should be set to theme.css, or custom-theme.css. I don't think web browsers understand the ?dev= part of that query.

  11. Install script needs better exceptions handling

    in Support

    Posted

    Hello.

    At some point though my installation I was encountering the following error:

    Database connection FAILED. Ensure that you have created the database and that the credentials are correct.

    However PHP modules were installed and the user name and password were correct. Further debugging revealed that the exceptions in install.php aren't handled properly. In the try catch block at line 469 I appended $e->getMessage() to the error and I finally figured out the problem:

    PHP's json extension is required to use Monolog's NormalizerFormatter

    So, I think the behavior needs to be changed accordingly.

    My best.

  13. Login with Display Name is a bad idea

    in Support

    Posted

    On 5/5/2018 at 1:26 AM, Paul said:

    I would suggest contacting IPBoard about any concern. Most organizations do not have secret usernames.. they force the use of email addresses, or display usernames publicly. Reddit, Twitter to name a couple allow you to login with your display name. I operate under the assumption that an attacker knows my username, but I can see how you'd want that to be secret. Nothing we can do about it though.

    The fact that many do it in one way doesn't mean it is right. Yes, there are techniques used to prevent brute force attacks or user escalation but can you foresee any vulnerabilities? Even yesterday Twitter asked users to reset their passwords... So, not sure Twitter is a good example.

  14. Login with Display Name is a bad idea

    in Support

    Posted

    On 5/5/2018 at 2:54 AM, Tyson said:

    It's always assumed that attackers have any username/email/etc. about you. Security through obscurity is not an acceptable deterrent.

    This is not security through obscurity. This is protecting my private data. Yes, attackers may be capable of obtaining the data (depending on how you protect it), it doesn't mean it should be made easy for them. I already provided the user escalation example... Security through obscurity isn't related to one practice. It should or could always be used in combination with more secure techniques, as security by design or open security. Security through obscurity may deter less apt attackers.

  15. Login with Display Name is a bad idea

    in Support

    Posted

    2 minutes ago, Blesta.Store said:

    oh you're talking about the Forum :) I thought you meant Blesta, the forum software does what the forum software developers do :) can't change that here.

    Well, too bad. But maybe Blesta team would consider opening a bug with the providers of the forum software.

  16. Login with Display Name is a bad idea

    in Support

    Posted

    On 5/2/2018 at 11:58 PM, Blesta.Store said:

    Display names? They can choose a Username or use their email address an attacker has to guess what the user is using?

    I am talking about the user name which are also used as display names. For example, can you login with Blesta.Store as user name? If yes, don't you notice an issue with that?

  17. Login with Display Name is a bad idea

    in Support

    Posted

    22 hours ago, Paul said:

    This was a change that IPBoard made.. after upgrading one day, users were forced to login with display name. Not aware of any account compromises, if you have a decent password, you should be fine, and we block brute force attacks.

    AFAIK the practice of displaying any details used for login helps attackers to exploit the system. The more info is provided about the internals of a system the easier it is for an attacker to exploit the system. Let's say there is a 0 day vulnerability an attacker found which allows user escalation. By investigating who is who on the forums it is super easy for the attacker to escalate to a user with extended rights.

×
×
  • Create New...