Login failure on backend 7.3 with correspondending frontend 7.3

[Stefan Groß]

Hello, I have a fresh install of the mentioned components, both behind a caddy reverse proxy (which offloads ssl) and all configured correctly after doublechecking everything metioned here:

https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-CommonInstallationIssues

especilly the parts about the "403 Forbidden" error with a message that says "Access is denied. Invalid CSRF Token" -- because that's the error I get trying to to log in to the newly created admin account through the frontend. Logins directly to the backend work just fine.

So I've gone through the traffic in the browser console (firefox), and compared it to the process described here:

https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

Before I try to login everything works fine. Just by loading the page the client does some requests to the backend, and on the first api request it gets an `DSPACE-XSRF-TOKEN` as described. It also gets the correspondendeding `DSPACE-XSRF-COOKIE`. Here the header of the response:

```

HTTP/2 200 OK
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-language: en
content-type: application/json;charset=UTF-8
date: Tue, 16 Aug 2022 14:42:42 GMT
dspace-xsrf-token: ead11d0b-33a5-4abd-8dc8-4fe78c11cb87
expires: 0
pragma: no-cache
server: Caddy
set-cookie: DSPACE-XSRF-COOKIE=ead11d0b-33a5-4abd-8dc8-4fe78c11cb87; Path=/server; Secure; HttpOnly; SameSite=None
strict-transport-security: max-age=31536000 ; includeSubDomains
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2

```

Later, still without doing anything but loading the page, the client even does a modifying request, and behaves just as described in the mentioned document on github: it sends an `X-XSRF-TOKEN` header and it sends an `DSPACE-XSRF-COOKIE`, and it gets an affirmative response. Here the request header:

```

POST /server/api/statistics/viewevents HTTP/2
Host: files.c8h10n4o2.gs
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json, text/plain, */*
Accept-Language: en;q=1,en-US;q=0.1,en;q=0.09
Accept-Encoding: gzip, deflate, br
Content-Type: application/json; charset=utf-8
X-XSRF-TOKEN: ead11d0b-33a5-4abd-8dc8-4fe78c11cb87
X-CORRELATION-ID: 73b9cd3c-dc49-42c8-aa3e-db1932836a78
X-REFERRER: /home
Content-Length: 71
Origin: https://files.c8h10n4o2.gs
DNT: 1
Connection: keep-alive
Referer: https://files.c8h10n4o2.gs/home
Cookie: DSPACE-XSRF-COOKIE=ead11d0b-33a5-4abd-8dc8-4fe78c11cb87; CORRELATION-ID=73b9cd3c-dc49-42c8-aa3e-db1932836a78; XSRF-TOKEN=ead11d0b-33a5-4abd-8dc8-4fe78c11cb87; dsLanguage=en
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
TE: trailers

```

As mentioned no errors whatsoever till now. But now I try to login on the page, and on submitting my email and pw the client produces a header which doesn't conform to the process described in giuthub. Namely, it does not send a `X-XSRF-TOKEN` header, it only sends the cookie, and seems to pack the header into the cookie. Here's the request headers:

```

POST /server/api/authn/login HTTP/2
Host: files.c8h10n4o2.gs
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json, text/plain, */*
Accept-Language: en;q=1,en-US;q=0.1,en;q=0.09
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
X-CORRELATION-ID: 73b9cd3c-dc49-42c8-aa3e-db1932836a78
X-REFERRER: /home
Content-Length: 56
Origin: https://files.c8h10n4o2.gs
DNT: 1
Connection: keep-alive
Referer: https://files.c8h10n4o2.gs/home
Cookie: DSPACE-XSRF-COOKIE=ead11d0b-33a5-4abd-8dc8-4fe78c11cb87; CORRELATION-ID=73b9cd3c-dc49-42c8-aa3e-db1932836a78; XSRF-TOKEN=ead11d0b-33a5-4abd-8dc8-4fe78c11cb87; dsLanguage=en; klaro-anonymous=%7B%22authentication%22%3Atrue%2C%22preferences%22%3Atrue%2C%22acknowledgement%22%3Atrue%2C%22google-analytics%22%3Atrue%7D; dsRedirectUrl=/home
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

```

The backend answers as expected. According to the document on github it does the following:

"During a modifying request, the REST API will compare the value of the CSRF token in the request's X-XSRF-TOKEN header to the value in the DSPACE-XSRF-COOKIE Cookie."

But since the client does not send a `X-XSRF-TOKEN` header, the comparison returns false (at least, that's what I think is the problem). Here the response headers and the response:

```

HTTP/2 403 Forbidden
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-type: application/json;charset=UTF-8
date: Tue, 16 Aug 2022 14:56:26 GMT
dspace-xsrf-token: fd073fbf-76e2-4555-84ef-b7d1830a5c87
expires: 0
pragma: no-cache
server: Caddy
set-cookie: DSPACE-XSRF-COOKIE=; Path=/server; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly; SameSite=None
set-cookie: DSPACE-XSRF-COOKIE=fd073fbf-76e2-4555-84ef-b7d1830a5c87; Path=/server; Secure; HttpOnly; SameSite=None
strict-transport-security: max-age=31536000 ; includeSubDomains
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2

{"timestamp":"2022-08-16T14:56:26.468+00:00","status":403,"error":"Forbidden","message":"Access is denied. Invalid CSRF token.","path":"/server/api/authn/login"}

```

I suspect this is a problem in the version of the client I try to run, but I'm not sure and I will happily provide any configs etc., if anyone would like to see them. To be sure about which version of the client I'm talking, I clone it with git like so:

```

git clone --depth 1 --branch dspace-7.3 https://github.com/DSpace/dspace-angular.git

```

I'm thankful for any corrections of my suspicion and pointers to the right direction, thx for reading.

__

s.

[Tim Donohue]

Make sure that that backend is running under HTTPS (and your frontend's "config.prod.yml" has "ssl: true" under it's "rest" configuration section).  When you see a 403 Forbidden with "Access is denied. Invalid CSRF Token" that usually means either the backend isn't running HTTPS (as required in production), or your frontend's "rest" settings are incorrect.  See this common issue for more details (and a few other things to try out): https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-%22403Forbidden%22errorwithamessagethatsays%22Accessisdenied.InvalidCSRFToken%22

If that doesn't help, you also may want to check for underlying errors in the frontend or backend. See our Troubleshooting guide for tips on doing that... it's always possible something else is blocking the CSRF verification process if an underlying error is occurring. https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

Good luck and let us know on this list if you find any more clues.

Tim

[Stefan]

Thx for the hints, but the "config.prod.yml" is correct, and I can login
to the backend (rest api) directly through https, so it is runnung
correctly. Also: following the troubleshooting guide you mentioned I
found that the requests generated by the frontend contain errors. As I
described. The short version: At the moment one tries to login, the
headers in the post request don't contain a header "X-XSRF-TOKEN",
but instead contain a coockie "X-XSRF-TOKEN=...". There is no "CSFR
Token" in the headers, and therefore the backend answers "Invalid
CSRF Token".

That's obviously an error that has nothing to do with the connectivity
to the backend, since the headers are generated in the frontend, and the
backend answers correctly. Instead of producing separate headers the
frontend produces a list of cookies. I'm not familiar with angular, so
I couldn't find the correspondending code with my limited javascript
skills, but there is somthing wrong concerning newlines vs. semicolons
or something like this in the generation of headers in the code.

I can imagine that the error does not bubble up during developement
since in local environments the wohle CSRF thing does not matter, but it
bubbles up in a production environment.

Tomorrow I will set up a vanilla demo with a dummy account and post a
link, so you can watch the error in your own browser dev-tools if you
like.

__
s.

> --
> All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
> ---
> You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/c493ede7-65d9-44fc-8ad5-df2931e58a46n%40googlegroups.com.

[Stefan Groß]

Ok, as I said, you can find a demo of the error here:

https://files.c8h10n4o2.gs

User: f...@bar.baz

PW: foobarbaz

To identify the error I refer to the protocol/procedure as documented here:

https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

Upon loading the page (without trying to login), you will be able (through the dev tools of your browser) to verify that the frontend does 21 requests, which all succeed (except for the google-analytics, since this is a vanilla installation). One of the requests is a post request, which requires csrf, and does it correctly, providing a "X-XSRF-TOKEN" header. It goes to the backend through https, to this endpoint: "/server/api/statistics/viewevents".

If you try to login now, this will also generate a post request, going to "/server/api/authn/login". But this request does not provide a "X-XSRF-TOKEN" header. Instead it provides a cookie, somehow mangled together from several headers, including the "X-XSRF-TOKEN" header. Therefore the response is negative.

If you want to verify that the account provided in this mail is working, you should empty your recent history or open a new incognito window, since the "DSPACE-XSRF-COOKIE" in your browser will be invalidated by the negative response from the login attempt through the frontend. Or you just try it twice, which will fail the first time but succeed the following times: Just login directly to the backend (the HAL-Browser) here:

https://files.c8h10n4o2.gs/server

__

s.

[Stefan Groß]

Sorry, somehow google groups seems to censor email addresses, the login User for the demo ist "foo" "AT" "bar" "dot" "baz".

__

s.

[Tim Donohue]

I took a glance at your REST API.  It's settings are incorrect, as you are including port 443 in all URLs.  When using standard ports (80 for HTTP or 443 for HTTPS), you do not need to include the port number. Doing so can cause issues.

So, on the backend, update your dspace.ui.url and dspace.server.url settings to use HTTPS *without* listing port 443.  You may need to restart the backend for the changes to take effect.

Tim

[Stefan]

OK, thx, I'll correct this tomorrow (it's evening now here), and will
report if it solves the issue. Obviously I missunderstood the docs on
that point.

__
s.

> To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/43f48c6a-0d3d-47a6-9b7e-e5b5e7eef143n%40googlegroups.com.

[Stefan Groß]

THX a lot, Tim, works like a charm now. :) (I couldn't go home right now because of a thunderstorm, so I tried immediately.)

__

s.