Little bug I think with wildcard subdomain

[ImagesGuru]

🎯Description of the issue

Icons in menu disappear with the transition to another language

▶🚶‍Reproduction steps

Enable wildcard subdomain and change language.

😢Unexpected result

📃Error log message

 

[ImagesGuru]

I just found an other bug.
When I go to https://images.guru, then I select a language in the menu (so I am now in fr.images.guru), then if I upload an image, the upload don't start.

 

[tomsit]

It's not a bug. You need CORS enabled.

 

[ImagesGuru]

It is enabled. My .htaccess :

# Enable CORS across all your subdomains (replace dev\.local with your domain\.com)
SetEnvIf Origin ^(https?://.+\.images\.guru(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1
Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN
Header merge Vary "Origin"

Note : can't reproduce the first bug (icone), think it was a cache problem. The second bug remains.

 

[Rodolfo]

Not a bug, and the fact is that your server is not doing CORS properly. Not script issue at all.

 

[ImagesGuru]

Not a bug, and the fact is that your server is not doing CORS properly. Not script issue at all.

For the upload not starting ? The first problem is solved.

 

[ImagesGuru]

Hello @Rodolfo,

I sent the problem to my host, he said that the error come from chevereto's error 400.

Hello,

Currently, if you look at the returned headers, they are fine, but your application returns a 400 error.

access-control-allow-headers: x-requested-with, Content-Type, origin, authorization, accept, client-security-token
access-control-allow-methods: POST, GET, OPTIONS, DELETE, PUT
access-control-allow-origin: *
access-control-max-age: 1000000
cache-control: no-cache, must-revalidate
content-type: application/json; charset=UTF-8
date: Wed, 14 Nov 2018 09:54:07 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
last-modified: Thu, 01 Jan 1970 00:00:00 GMT
pragma: no-cache
server: nginx
set-cookie: PHPSESSID=u9l74rhh0m655sbi4nb51e9f93; path=/; domain=.images.guru

You can see that the line: access-control-allow-origin is returned by our web frontend which is correct

However, when searching on your site, it is your application that returns error 400

Searching the files, here are the occurrences of the presence of line 400

app/routes/route.plugin.php:81: 'orange' => ['#d35400','#fff','#e67e22','#fff'],
app/routes/route.signup.php:195: throw new Exception("Can't insert user to the DB", 400);
app/routes/route.account.php:246: throw new Exception("Can't insert confirmation in DB", 400);
app/routes/route.account.php:360: throw new Exception('Unexpected error', 400);
app/routes/route.connect.php:138: throw new Exception('Twitter connect error code:'.$twitteroauth->http_code, 400);
app/routes/route.connect.php:154: throw new Exception('Twitter connect error: oauth callback not confirmed', 400);
app/routes/route.json.php:23: throw new Exception(_s('Request denied'), 400);
app/routes/route.json.php:34: throw new Exception(_s('Request denied'), 400);
app/routes/route.json.php:235: throw new Exception('Missing search term', 400);
app/routes/route.json.php:521: throw new Exception('Failed to edit category', 400);
app/routes/route.json.php:566: throw new Exception('Failed to edit IP ban', 400);
app/routes/route.json.php:1044: throw new Exception('Error deleting category', 400);
app/routes/route.json.php:1051: throw new Exception('Error deleting IP ban', 400);

For me, a control is done on your application outside our server which him returns the good headers.

 

[ImagesGuru]

Hello !
Some idea @Rodolfo ?
Thanks you.

 

[ImagesGuru]

I have moved to an another host, the problem is still here @Rodolfo

 

[Rodolfo]

Well, picking just one like "Failed to edit IP ban" gets you here:

                            if (!CHV\Ip_ban::update(['id' => $id], $editing)) {
                                throw new Exception('Failed to edit IP ban', 400);
                            }

And Ip_ban::update does this:

    public static function update($where=[], $values=[]) {
        try {
            if($values['ip']) {
                $values['ip'] = str_replace('*', '%', $values['ip']);
            }
            return DB::update('ip_bans', $values, $where);
        } catch(Exception $e) {
            throw new Ip_banException($e->getMessage(), 400);
        }
    }

If we pick another one, like "Error deleting category ":

                    $delete_category = CHV\DB::delete('categories', ['id' => $deleting['id']]);
                    if ($delete_category) {
                        $update_images = CHV\DB::update('images', ['category_id' => null], ['category_id' => $deleting['id']]);
                    } else {
                        throw new Exception('Error deleting category', 400);
                    }

I very clear that your DB is not working properly. Maybe you need to repair the table using the REPAIR command. If the DB is crashed then moving to another host won't fix anything.

Also, it could be that the permissions on the table are not properly set. In any case, I really doubt that these issues are related to the system, otherwise you shouldn't be the only person having this problem.

 

[ImagesGuru]

@Rodolfo I am on a very fresh install ... Others things except domain wildcard work fine.
Upload start well when I am on my domain. But don't start when I am on a subdomain.

Please stop keep saying that there is a problem with my database or my server ... and show me a demo how works with domain wildcard ..

Edit : repair on database don't did anything

 

[Rodolfo]

Did you missed the big yellow remark?



This is still an experimental feature and based on your feedback I can tell that you don't know how to properly setting up your server. You have a CORS issue which is very basic stuff. Also, if you are not going to try to understand our feedback then I don't know how to help you and certainly I won't make it work on your installation.

I throw you the code that catches these exceptions to show you why these gets triggered and your reply is "make it work on the demo". I reply you based on the information you provide and you feed me with log entries about some exceptions thrown by the system, so you get a reply on that.

Also, you don't digest anything... Here:

Upload start well when I am on my domain. But don't start when I am on a subdomain.

And the reply from @tomsit at Tuesday at 1:44 PM (3 days ago) was about CORS.

I tried to upload and I got this (please pay attention to the red console log entries):



CORS issue.

I strongly recommend you to either dish the idea of having subdomain wildcards or plain and easy, start paying attention to our feedback.

 

[ImagesGuru]

Hello @Rodolfo,

Thanks for the console log. I have done the samething and I have followed this tutorial : https://awesometoast.com/cors/

Now the upload start but I still have an error :
[Error] Failed to load resource: the server responded with a status of 400 (Bad Request) (json, line 0)

{
"status_code": 400,
"error": {
"message": "Demande refusée",
"code": 400,
"context": "Exception"
},
"request": {
"type": "file",
"action": "upload",
"timestamp": "1542394543179",
"auth_token": "41be37281b2fa231e34305d5deb5b929a65899a4",
"nsfw": "0"
},
"status_txt": "Bad Request"
}

But now no error about CORS.

 

[Rodolfo]

Request denied is issued when the auth token doesn't match. That happens when you alter how the cookies and sessions works on your website. The subdomain wildcards set cookie for the whole domain, but at the end is your server which delivers the content of the session.

Like I said, you should forget the idea of having subdomain wildcards because it is an experimental feature and is very clear that you aren't ok experimenting it, you only want it working asap wich won't be the case for your installation.

 

[ImagesGuru]

Thank you for your help @Rodolfo .
It's disappointing, this feature looked great. I will wait until it is more accomplished.

 

[Rodolfo]

Fixed.