datakick

June 7

System doesn't know your password. We only stores it's hash -- there's no way to determine your password from that.

You can use 'I forgot my password' functionality on your back office login page to generate a new password.

June 7

That module is not php8 compatible. You should probably stop using it, or ask author for a new version, or hire somebody to fix it for you.

In this particular case, the fix is very simple. Replace the

if ($this->_cookie_path{0} != '/') $this->_cookie_path = '/'.$this->_cookie_path;

with

if ($this->_cookie_path[0] != '/') $this->_cookie_path = '/'.$this->_cookie_path;

But who knows how many other issues that module contains.

June 7

If you can't remember your pwd, or if it's lost, you can either

recover new password - you will need to fix your email issues first. But you should do that anyway
create new admin user

June 7

13 hours ago, Madhosh said:

I tried this password. What's the existing password? Is it changeme1234

After the steps as described above, I am unable to create the new password.

The php script do not change your pwd. Use your original password, unless you broke it with manually changing stuff in the db.

June 5

3 minutes ago, DRMasterChief said:

What’s your take on additionally securing the admin page with an .htpasswd file?

A little bit unnecessary, since everything is protected behind admin pwd anyway.

One of the reasons to do this is to protect against any potential vulnerabilities in admin PHP files -- attacker can't exploit them if they can't access that portion of website in the first place. But there are not that many php files in /admin directory, so...

June 5

2 minutes ago, nickz said:

Knowing the admin name a hacker just uses the php script

that's why the recovery steps explicitly says:

Quote

delete force-login.php script

June 5

1 minute ago, nickz said:

You can monitor your shop and all files, it does not cost the world.
A little self responsibility is not wrong to have. If that would be optional it would be user friendly.
Truth be told I'd liked best TB1.3.

Not really sure what are we talking here about.

The fix for this problem was, previously, to change password directly in database. Which would, in fact, be a bit more complicated than it was written in the post above, because plain md5 would not work. The password would have to be salted with _COOKIE_KEY_ for this mechanism to work. You could, however, insert any password generated by php function password_hash.

The new solution is to use a php script to log in into your server.

To me, those two solutions are similar in complexity. For a lot people the new solution might even be easier, as it's just upload file using FTP. Changing data directly in database may be more scary.

June 5

54 minutes ago, nickz said:

Well you guys will make TB so secure that the owner can not get back into the BE.

As it should be.

SQL injections are really bad, of course, as attacker can extract or change all informations in your store.

But gaining access to PHP side is much more severe. Attacker can then do anything they want.

Making it impossible for store owners to change email and password manually in database is a small price to pay.

June 5

The approach described by @DRMasterChief will not work on newer versions of thirty bees, intentionally.

You can check if your tb_employee table contains column signature - if the column exists, you can't change the email/password in the table manually. You also need to change the value of column signature, but for that you need to know a secret that's not available to mysl.

This mechanism exists to prevent attackers to elevate sql injections into complete access. If your store contained SQL-injection vulnerability (often caused by older third party modules), attacker could use it to change admin password, and then log in (basically the same mechanism described above). With the requirement to change signature as well, this no longer works.

You can use force-login php script to log into your admin, see this post:

You will have to:

upload force-login.php file into your admin123xyz directory (every installation have different admin folder name)
open url https://your.store/admin123xyz/force-login.php
this will logs you in as an admin
change password
delete force-login.php script

June 4

Fixed in commit https://github.com/thirtybees/thirtybees/commit/7e9f2db06acd8323d4cefef0bb44654b87e6f0ca

June 4

This Attempt to update unsaved object warning message exists to alert developers to a code that do something they probably do not expect.

In this case, FrontController is trying to update Cart object and set language/currency. But because the cart does not exists, that update is silently ignored - nothing is actually saved/updated into database. This is obviously strange situation that needs to be investigated and fixed. In this case, we should can simply add a check that cart exists before we try to do any of this stuff. In a lot of other cases, the fix may be much more complicated.

June 3

You need to update your theme and remove dependency on polyfill.io

This is how we did it in niara theme: https://github.com/thirtybees/niara/commit/3ab40e7ae52e0c495a2b67f09131996fb6ed65ea

For your theme, it will be mostly the same - edit file header.tpl, find line with polyfill.io, and delete it.

June 3

12 hours ago, DRMasterChief said:

...once again, how to fix this with PHP 8.1 ? Please help @datakick

Is that simply sufficient?

in /controllers/front/TriggerController.php

// BEFORE:
trigger_error("Attempt to update unsaved object", 512);

// AFTER:
@trigger_error("Attempt to update unsaved object", 512);

I'm not sure what is the question. There is no

trigger_error(...)

in TriggerController.

April 24

16 hours ago, DRMasterChief said:

I'd really like to know what database size we're talking about here? Are you planning to import a database, or what exactly are you doing?

This is related to MAX_JOIN_SIZE configuration variable in mysql server. From documentations:

If the max_join_size variable (also called sql_max_join_size) is set, then it will limit
any SELECT statements that probably need to examine more than MAX_JOIN_SIZE rows.

This means that database server (during preparation stage) will estimate how many rows it will need to process (based on table statistics). If the estimate is above threshold, it will refuse to execute the query.

This is set on some shared hostings to achieve some kind of fair usage between all users.

Sometimes we can indeed optimize the query, or create a new db indexes so the join space is not so huge. But sometimes its just not possible.

I still maintain that this is stupid and dangerous practice by hosting providers. This can kill any sql query, and therefore cause a lot of 500 error pages. Ecommerce store should not run on such hosting.

April 23

There is a potential workaround here. You can set SQL_BIG_SELECTS variable for a database session. That should allow you to bypass the error (may or may not work, depending on your hosting configuration)

Create a new override

override/classes/db/Db.php

with this content:

<?php

class Db extends DbCore
{
    /**
     * This override allows complex queries to run on shared hosting
     */
    public function connect()
    {
        $link = parent::connect();
        $link->exec('SET SQL_BIG_SELECTS = 1');
        return $link;
    }
}

Then clear cache in Advanced Parameters > Performance to reload the overrides

April 23

Well sure, you can remove old data, it will reduce the number of rows db have to examine.

But still, the root cause of the issue is that your hosting is throttling your database. We send them valid sql request, and they may or may not return results. This is just stupid. Who knows what other sql queries they will kill randomly. This "fair usage mechanism" can cost you sales.

But that's sharing hosting. You can always move to a dedicated hosting without such restrictions

April 23

This is your hosting restrictions. You are probably on a shared hosting, and they have enabled this restriction to ensure fair usage for all customers.

Ask them if they can disable this.

April 17

Oh, I didn't even noticed this was ps16.

Yeah, Alex, you should thoroughly test your store, because this will not be the only problem. If possible, downgrade your php version. Or even better, migrate to thirtybees.

April 17

Hi Alex,

did you install some new module, or changed you PHP version recently?

Anyway, this issue is caused by an override. You need to edit file

/override/controllers/admin/AdminLoginController.php

and replace code

 public function viewAccess()

with

 public function viewAccess($disable = false)

That should do the trick

April 7

5 hours ago, led24ee said:

I have this module. Somehow there is error. When client get this email there is only language relates flag picture instead of product picture. Can someone point me in correct direction to find out why is this ? I haven't changed anything in system. So I have no idea what can be the cause.

I checked the code, and revws module only supports jpg files. Which was ok in the past, but now when you can have your product images in webp or other formats, it can cause troubles.

If your store uses webp images, edit file

modules/revws/controllers/front/EmailAction.php

and change lines

    private function getImage(RevwsEmail $email)
    {
        $email->markOpened();
        $imageId = (int)$this->getValueOrThrow('image-id');
        $type = $this->getImageType();
        $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . $type . ".jpg";
        if (!file_exists($file)) {
            $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . ".jpg";
        }

to

    private function getImage(RevwsEmail $email)
    {
        $email->markOpened();
        $imageId = (int)$this->getValueOrThrow('image-id');
        $type = $this->getImageType();
        $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . $type . ".webp";
        if (!file_exists($file)) {
            $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . ".webp";
        }

I will fix this in next version of module

February 13

23 minutes ago, theMerchantDev said:

And check every day.

with a busy store that's quite hard to do, though. We have an installation with average of 1M daily requests, that's hard to comb though manually. You can install some software to detect anomalies, but that's it.

When you find an infection on your store, you know from the file modification date when it happen (unless the script changed it, but in my experience they rarely do), so that can help a lot. You just need to detect it and still have access logs

February 13

14 hours ago, x97wehner said:
They do outline the script code to look for. I just searched my website via f12 and then looked through the website code via MS Code and didn't find this expression anywhere, so I assume that I am not affected. "
<script>(function(){var x=new XMLHttpRequest;x.open('GET',atob"

Yes, if this code exists in your tpl files, it means your store is already infected. But the fact that it isn't present doesn't mean your store is not vulnerable to this attack.

We don't know about any vulnerability in the core that would allow attacker to modify/write to tpl files. We regularly check CVE database for prestashop vulnerabilities, and look for those that are relevant to ps16 codebase (so they are relevant to us, most likely). Again, that doesn't mean that they don't exists, we just don't know about any at the moment. But there were some that we have fixed in the past - running very old thirty bees versions is not encouraged.

Most of the time the culprits are third party modules, usually those that allow uploading files (images usually) and do not properly sanitise inputs. That may allow attacker to upload php files instead of image, and then they have complete access to your entire store.

Thankfully, you can use core updater module to check if any of the core files have been modified. If your store is infected, you will see it there as well.

If your store is infected, it's not enough to just remove the infection. You need to find out the back door that was used to install the infection. That can be quite hard. Your server access logs can help a lot, so keep a few months of them if you can.

February 12

They didn't disclose attack vector - we don't know how those shops were infected with this malware. Without that information we can't really say if thirty bees is affected or not.

January 13

No need to fix anything, this is merely a notice for developers to investigate the surrounding logic. And we did that 🙂

With or without the fix, the end result is the same - nothing actually happens when the object (cart) is not already saved in the database.

January 13

You can safely ignore this. This was already fixed in bleeding edge, see comit https://github.com/thirtybees/thirtybees/commit/3c8447874a71825a1561fb2edb5371ee8249375b

Sign In

datakick

Posts

Joined

Last visited

Days Won

Content Type

Profiles

Forums

Gallery

Downloads

Articles

Store

Blogs

Posts posted by datakick

Need help

Need help

Need help

Need help

Need help

Need help

Need help

Need help

Need help

What is the function of the trigger controller?

What is the function of the trigger controller?

URGEND - polyfill.io login window suddenly appearing on my thirty bees store

What is the function of the trigger controller?

Invalid list SQL

Invalid list SQL

Invalid list SQL

Invalid list SQL

Can't Suddenly login to backoffice

Can't Suddenly login to backoffice

[Free Module]Revws - Product Reviews

Prestashop security alert. Is TB affected?

Prestashop security alert. Is TB affected?

Prestashop security alert. Is TB affected?

Attempt to update unsaved object , TB 1.6

Attempt to update unsaved object , TB 1.6