Sorry, somehow google groups seems to censor email addresses, the login User for the demo ist "foo" "AT" "bar" "dot" "baz".
__ s. On Thursday, August 18, 2022 at 12:13:21 PM UTC+2 Stefan Groß wrote: > Ok, as I said, you can find a demo of the error here: > > https://files.c8h10n4o2.gs > User: [email protected] > 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. > > > On Thursday, August 18, 2022 at 12:09:23 AM UTC+2 Stefan Groß wrote: > >> 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/7e36ece0-9adc-4624-b72b-0fbbee6e4088n%40googlegroups.com.
