[uberspace] Comments gone after reload

[p-vitt]

I'm running isso 0.10.6 installed via pip on uberspace7 and added it (embed.min.js) to my Pelican driven blog. When loading the page, I can see the form and also the text that there is no comment yet, but when I try to submit a comment, I get a 403 on the POST request.

The request was

Accept: / Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.5 Connection: keep-alive Content-Length: 180 Content-Type: application/json Cookie: 4=WzQsIjg0MDQ1NGQwNDFlNjUyMmQ2NTE2NzNmNTdlNDlmOTQ2N2ZkYzdlYTgiXQ.DaZoLw.YCChMYMt4mQPoCNrY2MPndQ1sBQ; 5=WzUsIjUyMjVhZWJkMmI4YzQyZDBhYmY5ZjAzN2I5NTI5M2NkZmQ4MTM4YWYiXQ.DaZoOw.Rl2ZxtdGnsbksZWaDpC1rdi0HAY; 6=WzYsIjhjYTE4N2QzYjRhOGU0ZGRiOWQzMjBiMTE1YjkyYjRlOGUxYThmOWMiXQ.DaZpZw.mN6xd0BMG8NehUY6t2txP05kC5M DNT: 1 Host: isso.mydomain.de Origin: https://mydomain.de Referer: https://mydomain.de/ User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:59.0) Gecko/20100101 Firefox/59.0

and the response is

HTTP/2.0 403 Forbidden access-control-allow-credentials: true access-control-allow-headers: Origin, Referer, Content-Type access-control-allow-methods: HEAD, GET, POST, PUT, DELETE access-control-allow-origin: https://mydomain.de access-control-expose-headers: X-Set-Cookie, Date content-length: 153 content-type: text/html; charset=UTF-8 date: Wed, 04 Apr 2018 13:57:09 GMT referrer-policy: strict-origin-when-cross-origin server: nginx strict-transport-security: max-age=172800 x-content-type-options: nosniff X-Firefox-Spdy: h2 x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block

Did I miss something in the docs? Do I need to adjust some file access? Any help appreciated.

[p-vitt]

I tried again (after some time) with error logging enabled. Now I have the same behavior as before, which I was not able to reproduce when I wrote this issue and thus thought that it was some setup glitch:

1. I write a comment and submit it via the submit button.
2. The comment is shown below the textbox.
3. The database grows, at least the filesize is increased. Also the access time was modified.
4. When reloading the page, the comment isn't shown.

[p-vitt]

I checked the database, which actually contains comments. To me it seems that the link between the comment and the website is somehow broken.

[p-vitt]

The database contains comments in the comment table like this one:

(
    1, 
    8, 
    None, 
    1522853745.6648319, 
    None, 
    1, 
    u'2003:00e6:f3c5:0000:0000:0000:0000:0000', 
    u'testkommentar', 
    u'p', 
    u'i@my.home', 
    None, 
    0, 
    0, 
    <read-write buffer ptr 0x8958f0, size 256 at 0x8958b0>
)

and it also contains the site url in the threads table:

[(1, u'/my-super-post.html', None), (2, u'/another-great-post.html', None)]

[blatinier]

In the comment table you have a reference to the thread table (tid column). The thread holds the uri which refers to your page. Could you paste here your isso.conf and maybe the list of calls (method, url, httpStatus, without payload) done by the browser.

[p-vitt]

~/etc/isso/user.cfg:

$ cat etc/isso/user.cfg [general] dbpath = /home/sw7/etc/isso/comments.db host = https://stockwart.de/ [server] listen = http://localhost:61728

Calls from the browser:

https://isso.stockwart.de/count OPTIONS 200 https://isso.stockwart.de/?uri=/my-super-post.html&nested_limit=5 OPTIONS 200 https://isso.stockwart.de/?uri=/my-super-post.html&nested_limit=5 GET 404 https://isso.stockwart.de/count POST 200

[blatinier]

I suppose you have some proxy (apache/nginx…) could paste the proxifying conf?

[p-vitt]

I guess this is what you are looking for, right?

$ cat ~/html/.htaccess RewriteCond %{HTTP_HOST} ^(www.)isso.stockwart.de [NC] RewriteRule ^(.) http://localhost:61728/$1 [P,L]

[blatinier]

Do you have access to your apache/nginx configuration? Because defining a proxy in htaccess is equivalent to setting ProxyPass in apache but you can't set any equivalent for ProxyPassReverse directive and I'm not sure it's optionnal.

[p-vitt]

I can read /var/www/html/.htaccess:

$ cat /var/www/html/.htaccess
RewriteEngine On

# show a info page for all domains, except for subdomains of uberspace.de and ubrspc.de
RewriteCond %{HTTP_HOST} !\.uberspace\.de$
RewriteCond %{HTTP_HOST} !\.ubrspc\.de$
# ipv4
RewriteCond %{HTTP_HOST} !\.[0-9]+$
# ipv6
RewriteCond %{HTTP_HOST} !]$
RewriteRule ^$ unknowndomain.html

This doesn't look suspicious. Unfortunately, I'm not allowed to read /etc/nginx/. But there are also people using isso on the same shared hoster, e.g. https://fryboyter.de/der-umzug-auf-uberspace-7, so I doubt that the solution to this lies in the systemwide config.

[blatinier]

Could you try without dynamically injecting the javascript the first to be sure that's not the issue?

[p-vitt]

I removed the script to lazyload the embed.min.js and put it into the header, but it's still not working.

[blatinier]

If you have access to the db it would be great to dump the content of the threads table

[p-vitt]

I already posted the content as I read it in python here. Here is also a sql dump:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE threads (     id INTEGER PRIMARY KEY, uri VARCHAR(256) UNIQUE, title VARCHAR(256));
INSERT INTO "threads" VALUES(1,'/my-super-post.html',NULL);
INSERT INTO "threads" VALUES(2,'/another-great-post.html',NULL);
CREATE TRIGGER remove_stale_threads AFTER DELETE ON comments BEGIN     DELETE FROM threads WHERE id NOT IN (SELECT tid FROM comments); END;
COMMIT;

[blatinier]

I think that the problem is that when the js tries to fetch comments, the server somehow fails to link the given uri to the corresponding thread. But I don't know why... Could you try adding isso.stockwart.de to host?

host =
    https://stockwart.de
    https://isso.stockwart.de

[p-vitt]

Changed it accordingly, no success... Can I run isso in some kind of debug mode to get some knowledge about what's going on?

[p-vitt]

I tried to get a deeper understanding of what is going on when I load a page with isso comments. Please correct me, if I'm wrong.

As far as I can see, isso requests end up in views/comments.py. The browser shows these requests:

https://isso.stockwart.de/count OPTIONS 200
https://isso.stockwart.de/?uri=/my-super-post.html&nested_limit=5 OPTIONS 200
https://isso.stockwart.de/?uri=/my-super-post.html&nested_limit=5 GET 404
https://isso.stockwart.de/count POST 200

In views/comments.py, the VIEWS dict in class API seems to connect the handler functions with the requests. According to this list, /count POST should end up in API.counts, while /?uri=/my-super-post.html&nested_limit=5 GET should end up in API.fetch. Is this correct so far?

I can see that API.counts is called, but API.fetch is not called. Is this observation meaningful in any way? Or did I just misunderstand the code?

[blatinier]

You are right, but the reason why fetch is not called is obscure... Can you try setting data-isso-id="whatever-relevant-id-for-your-post" in the <section id="isso-thread"> tag?

Like this:

<section id="isso-thread" data-isso-id="whatever-relevant-id-for-your-post">

[p-vitt]

This results in

$ isso -c ~/etc/isso/user.cfg run
2018-04-06 13:06:32,874 INFO: Running WSGIServer
__init__ called
2018-04-06 13:06:33,365 INFO: connected to https://stockwart.de
127.0.0.1 - - [2018-04-06 13:06:45] "GET /js/embed.min.js HTTP/1.1" 304 409 0.001684
127.0.0.1 - - [2018-04-06 13:06:46] "OPTIONS /count HTTP/1.1" 200 364 0.000479
127.0.0.1 - - [2018-04-06 13:06:46] "OPTIONS /index.html?uri=whatever-relevant-id-for-your-post&nested_limit=5 HTTP/1.1" 200 364 0.000304
counts called
127.0.0.1 - - [2018-04-06 13:06:46] "POST /count HTTP/1.1" 200 372 0.003482
127.0.0.1 - - [2018-04-06 13:06:46] "GET /index.html?uri=whatever-relevant-id-for-your-post&nested_limit=5 HTTP/1.1" 404 605 0.001195

When I change the VIEWS map in views/comments.py from:

VIEWS = [
    ('fetch',   ('GET', '/')),
    ....

to

VIEWS = [
    ('fetch',   ('GET', '/index.html')),
    ....

at least API.fetch is called, although it still returns 404.

[p-vitt]

Hmm, after removing the data-isso-id, it seems to work.

[blatinier]

Just a precision, here the 404 can mean that the thread you require has no comments attached to it. This means it fails to fetch comments from the thread uri you gave.

As for the index.html it's really strange. I can't think of why this makes the thing work…

[p-vitt]

Also loading the JS on demand is working now.

So the question seems to be: Why is there a /index.html, or the other way round, why is it not matched?

[p-vitt]

Hmm, I guess the index.htmlshouldn't be there, right?

[M4a1x]

Hey, fellow uberspace user here. I spent basically my whole day today trying to get this to work. I had exactly the same problem with the form showing up, the comments could be submitted, but wouldn't show up after a reload.

The Solution was to add DirectoryIndex disabled as the first line in the .htaccess file for the domain the isso server is running on.

[p-vitt]

Dude, that's where the index.html is coming from. Thanks for letting me (us) know. I'll revert my local isso right away and add this line to .htaccess. Stay tuned...

[p-vitt]

I had to create a new documentroot (DR) for isso.stockwart.de next to the common DR. I moved the .htaccess from the common DR to the new DR, as it only contained two lines to forward all requests to isso.stockwart.de to the port where isso is listening. I also added the DirectoryIndex disabled as suggested. Works like a charm.

Thanks again for pointing this out.

I guess this issue is settled then, thus closing it.

[blatinier]

Reopening as it could be useful to put that in the documentation for future uberspace users.

[tareefdev]

I have the same problem here.

I was using Hugo for my blog for several years now, and everything works well. I moved to Gatsby and have the same issue described here; comments have gone after reload the page.

If you visit the blog and click on the first link then scroll down, 6 comments would be shown there. Now press F5 to refresh the page and scroll down again, now nothing appears there!

That happens with all my posts; even there was no comments on a post after reloading the page, the isso issue box itself will go.

I use Nginx not Apache so no place to add DirectoryIndex disabled, I didn't change the domain, neither the URLs of posts.