Unable to register #137

New Issue

jtojnar · 2020-02-15T09:35:02Z

jtojnar commented

2020-02-15 09:35:02 +00:00

When I try to register on the front page of my instance (running #135), the request fails with 404 Not Found. Same thing happens if I try to send the same request to the app directly using:

curl -L 'http://localhost:5001/api/v1/register' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: cs,en-US;q=0.7,en;q=0.3' --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Origin: https://****' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://****/register' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: Trailers' --data '{"username":"jtojnar","email":"****","password":"****"}'

When I try to register on the front page of my instance (running #135), the request fails with `404 Not Found`. Same thing happens if I try to send the same request to the app directly using: ``` curl -L 'http://localhost:5001/api/v1/register' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: cs,en-US;q=0.7,en;q=0.3' --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Origin: https://****' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://****/register' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: Trailers' --data '{"username":"jtojnar","email":"****","password":"****"}' ```

jtojnar commented

2020-02-15 09:52:33 +00:00

In the nikunja.service journal I am getting

Feb 15 09:19:47 azazel api[152532]: 2020-02-15T09:19:47.639165103+01:00: WEB         ▶ 127.0.0.1  POST 404 /api/v1/register 685.006µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Strangely, after I rebooted the server it worked:

Feb 15 10:34:35 azazel api[154520]: 2020-02-15T10:34:35.877559754+01:00: WEB         ▶ ::1  POST 200 /api/v1/register 534.174277ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Now I am getting 404 on

Feb 15 10:46:54 azazel api[156471]: 2020-02-15T10:46:54.319487979+01:00: WEB         ▶ 127.0.0.1  GET 404 /api/v1/migration/wunderlist/auth 222.019µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:47:03 azazel api[156471]: 2020-02-15T10:47:03.428846757+01:00: WEB         ▶ ::1  GET 400 /api/v1/migration/wunderlist/auth 83.207µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

(The error 400 is when I visited the URL in the browser.)

In the `nikunja.service` journal I am getting ``` Feb 15 09:19:47 azazel api[152532]: 2020-02-15T09:19:47.639165103+01:00: WEB ▶ 127.0.0.1 POST 404 /api/v1/register 685.006µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 ``` Strangely, after I rebooted the server it worked: ``` Feb 15 10:34:35 azazel api[154520]: 2020-02-15T10:34:35.877559754+01:00: WEB ▶ ::1 POST 200 /api/v1/register 534.174277ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 ``` Now I am getting 404 on ``` Feb 15 10:46:54 azazel api[156471]: 2020-02-15T10:46:54.319487979+01:00: WEB ▶ 127.0.0.1 GET 404 /api/v1/migration/wunderlist/auth 222.019µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:47:03 azazel api[156471]: 2020-02-15T10:47:03.428846757+01:00: WEB ▶ ::1 GET 400 /api/v1/migration/wunderlist/auth 83.207µs - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 ``` (The error 400 is when I visited the URL in the browser.)

jtojnar referenced this issue

2020-02-15 09:54:18 +00:00

Add postgres support #135

jtojnar commented

2020-02-15 10:01:10 +00:00

It is also weird how it oscillates between IPv6 and IPv4.

Feb 15 10:46:02 azazel api[156471]: 2020-02-15T10:46:02.2729724+01:00: WEB         ▶ ::1  POST 200 /api/v1/register 256.701327ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:02 azazel api[156471]: 2020-02-15T10:46:02.739362394+01:00: WEB         ▶ 127.0.0.1  POST 200 /api/v1/login 246.675803ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:03 azazel api[156471]: 2020-02-15T10:46:03.365152279+01:00: WEB         ▶ 127.0.0.1  GET 200 /api/v1/tasks/all?sort_by[]=due_date_unix&sort_by[]=id&order_by[]=desc&order_by[]=desc&page=1 14.300239ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:03 azazel api[156471]: 2020-02-15T10:46:03.368511112+01:00: WEB         ▶ ::1  GET 200 /api/v1/namespaces?page=1 16.259887ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.168125722+01:00: WEB         ▶ ::1  POST 200 /api/v1/register 244.204945ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.594294962+01:00: WEB         ▶ 127.0.0.1  POST 200 /api/v1/login 235.410377ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.772292269+01:00: WEB         ▶ 127.0.0.1  GET 200 /api/v1/tasks/all?sort_by[]=due_date_unix&sort_by[]=id&order_by[]=desc&order_by[]=desc&page=1 12.479618ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

but that does not seem to affect the success rate.

I am using proxy_pass with nginx as described on https://vikunja.io/docs/reverse-proxy/.

It is also weird how it oscillates between IPv6 and IPv4. ``` Feb 15 10:46:02 azazel api[156471]: 2020-02-15T10:46:02.2729724+01:00: WEB ▶ ::1 POST 200 /api/v1/register 256.701327ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:02 azazel api[156471]: 2020-02-15T10:46:02.739362394+01:00: WEB ▶ 127.0.0.1 POST 200 /api/v1/login 246.675803ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:03 azazel api[156471]: 2020-02-15T10:46:03.365152279+01:00: WEB ▶ 127.0.0.1 GET 200 /api/v1/tasks/all?sort_by[]=due_date_unix&sort_by[]=id&order_by[]=desc&order_by[]=desc&page=1 14.300239ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:03 azazel api[156471]: 2020-02-15T10:46:03.368511112+01:00: WEB ▶ ::1 GET 200 /api/v1/namespaces?page=1 16.259887ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.168125722+01:00: WEB ▶ ::1 POST 200 /api/v1/register 244.204945ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.594294962+01:00: WEB ▶ 127.0.0.1 POST 200 /api/v1/login 235.410377ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 Feb 15 10:46:22 azazel api[156471]: 2020-02-15T10:46:22.772292269+01:00: WEB ▶ 127.0.0.1 GET 200 /api/v1/tasks/all?sort_by[]=due_date_unix&sort_by[]=id&order_by[]=desc&order_by[]=desc&page=1 12.479618ms - Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 ``` but that does not seem to affect the success rate. I am using `proxy_pass` with nginx as described on https://vikunja.io/docs/reverse-proxy/.

konrad commented

2020-02-15 10:19:11 +00:00

The 404 from the register route could be caused by disabling registration, but unless you explicitly set it up that way, it should not occur.

Are you running this with postgres? It could be the other errors are coming from the fact Vikunja has issues with postgres for now.

The 404 from the register route could be caused by disabling registration, but unless you explicitly set it up that way, it should not occur. Are you running this with postgres? It could be the other errors are coming from the fact Vikunja has issues with postgres for now.

konrad commented

2020-02-15 10:20:26 +00:00

Normally, when you get a 400 error, you should see an error message in the frontend or at least in network tab of the browser inspector.

Normally, when you get a `400` error, you should see an error message in the frontend or at least in network tab of the browser inspector.

jtojnar commented

2020-02-15 10:34:37 +00:00

The 404 from the register route could be caused by disabling registration, but unless you explicitly set it up that way, it should not occur.

I did not create the registration env var and I do not have a config file so I would expect the default to apply.

Are you running this with postgres? It could be the other errors are coming from the fact Vikunja has issues with postgres for now.

Yes. But would not those show as error 500 like vikunja/api#135 (comment) instead of 404?

Normally, when you get a 400 error, you should see an error message in the frontend or at least in network tab of the browser inspector.

Yes that one is not an issue, I just accidentally opened the link by double clicking the 404 request in the Network panel of devtools and it opened as regular GET without JWT.

> The 404 from the register route could be caused by disabling registration, but unless you explicitly set it up that way, it should not occur. I did not create the registration env var and I do not have a config file so I would expect the default to apply. > Are you running this with postgres? It could be the other errors are coming from the fact Vikunja has issues with postgres for now. Yes. But would not those show as error 500 like https://kolaente.dev/vikunja/api/pulls/135#issuecomment-5544 instead of 404? > Normally, when you get a 400 error, you should see an error message in the frontend or at least in network tab of the browser inspector. Yes that one is not an issue, I just accidentally opened the link by double clicking the 404 request in the Network panel of devtools and it opened as regular GET without JWT.

konrad commented

2020-02-15 11:14:32 +00:00

I would expect the default to apply.

Yes, defaults should apply.

Yes. But would not those show as error 500 like #135 of 404?

Also yes. 404s only occur when the route has not been registered in the cases you mentionend.

> I would expect the default to apply. Yes, defaults should apply. > Yes. But would not those show as error 500 like #135 of 404? Also yes. 404s only occur when the route has not been registered in the cases you mentionend.

konrad commented

2020-02-17 16:49:55 +00:00

Do you still get these issues?