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. On Thursday, August 18, 2022 at 7:24:59 PM UTC+2 Stefan Groß wrote: > 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. > > > On Thu, Aug 18, 2022 at 06:55:14AM -0700, 'Tim Donohue' via DSpace > Technical Support wrote: > > 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 > > > > On Thursday, August 18, 2022 at 5:15:27 AM UTC-5 [email protected] > wrote: > > > > > 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/43f48c6a-0d3d-47a6-9b7e-e5b5e7eef143n%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/27cf41a8-84c5-420d-aa59-9ede49130662n%40googlegroups.com.
