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. On Wed, Aug 17, 2022 at 02:14:52PM -0700, 'Tim Donohue' via DSpace Technical Support wrote: > 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 > > On Tuesday, August 16, 2022 at 11:22:22 AM UTC-5 [email protected] wrote: > > > 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. > > > > > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dspace-tech/c493ede7-65d9-44fc-8ad5-df2931e58a46n%40googlegroups.com. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/Yv1nDUgFFvuwu1Gl%40localhost.localdomain.
