Users logging in with Google connector do not have access to images

[Giorgio-Bonvicini-R4P]

Describe the bug

I am experiencing a similar issue to #667 - this variant seems to be connected to how the user logs in (email+password VS google connector).

Details:

• Users who login with username and password see images in questions and answers OK
• Users who login with Google (using the google connector plugin) do not see the same images (instead they get the 403 error, same as picture not diplay normally #667)

Additional info:

• If a non-existing user logs in with google (so their account is created at that moment), they can not see the image. If they log out, the admin sets a password for them and they log back in with email and password, the can see the image.
• If a user is created with email and password and logs in with email and password they can see the image. If they log out and log in with google, they can not see the image anymore.
• A user who cannot see the image is not able to see it both in the posts and directly accessing the URL (redirect to 403)
• Regarding cookies: I observed that if the same user logs in with email+password first receives a certain cookie visit=UID. Using curl with this cookie retrieves the image OK (HTTP 200). If the user logs out and back in with Google they keep the same cookie, but now the same curl command fails (302 to the 403 page).
• Sometimes, if the user logs in with email+password, logs out and back in with google, the image seems to load ok, but it's only "cached", and after a few refresh/cache clean/Shift+R it gets back to the usual erorr 403. Curl instead seems to fail immediately
• All behaviors are reproduceable in Chrome and Firefox on multiple PCs

To Reproduce

Steps to reproduce the behavior:

1. Login using google authenticator (either on a new account or on an account previously created with email+password)
2. Open a question (possibly posted by another user, not sure if the same problem is present with images posted by the same account) with an image in the body
3. Observe that the image is broken
4. Try to open the image directly via its URL -> get a redirect to 403 error page

Expected behavior

All users should be able to see all images as long as they are logged in correctly.

Screenshots

Example of broken image in the post body:

Example of 403 redirect when accessing the image URL directly.

Platform

• Device: Desktop
• OS: Debian 12 Bookworm
• Browser and version: Verified in both Chrome and Firefox
• Version: latest (1.5.0) - Installed with docker (can provide docker and configuration files if necessary)

Tagging @LinkinStars to continue the previous interaction.

[Giorgio-Bonvicini-R4P]

I tried to run some other scenarios, but could not find any additional data except that if a user logs in with Google they are not even able to see images they are uploading themselves

All behaviors described in my original issue are confirmed.

I am not very well versed with Go, but if there is anything I can try to test and fix this please let me know.

[LinkinStars]

@Giorgio-Bonvicini-R4P

Thanks for the reply. Let me clarify: We have been looking for the cause of the problem for a while, but have not been able to reproduce it. Let's explain the environment and the steps we took to test it.

1. Using the latest version of Apache Answer
2. Using the HTTPS deployment of the domain name
3. Set login required to true

Steps

1. Use your browser's privacy mode to ensure that there is no caching.
2. Click Login to go to the Google login
3. Successfully logged in and returned to the Answer, and uploading and accessing images work fine.

---

You can follow the steps shown in the image below to make sure that the following cookie exists or not after logging in, and if it doesn't exist, there is no way to access the image(in login-required mode). In case you are not able to access the image, you can see if there is an error log present. Thank you for your help.

[Giorgio-Bonvicini-R4P]

First of all I can confirm:

• Using the latest version of Apache Answer
• Using HTTPS (although not natively: I am using Traefik as reverse porxy)
• "login required" is set to true

That being said, I think we might have something useful at hand.

First of all, reproducing your exact steps (open Chrome with private navigation, login with Google, craete new answer with image), the image loads correctly! (and the cookie is there)

Now, my suspicion was that it is somehow related to cookies being re-used/not invalidated correctly.

So I tried this:

1. open the website in Chrome with private navigation
2. as expected, no cookie is set
3. login with google
4. cookie gets set to visit=XYZ
5. creating a new question with an image, it loads OK
6. opening an old question with an image, it loads OK
7. log out (Chrome still open with private navigation)
8. the cookie is still set to visit=XYZ (same as before, this is what looks suspicious to me)
9. login with google (same user as before)
10. the cookie is still set to visit=XYZ (same as before, even more suspicious)
11. creating a new question with an image, it FAILS to load
12. opening an old question with an image, it seems to load ok, but it is just cached. If I force reload without cache (Ctrl+Shift+R) the image FAILS to load

Additionally:

1. open the website in Chrome with private navigation
2. as expected, no cookie is set
3. login as user1 with user and password
4. cookie gets set to visit=XYZ
5. creating a new question with an image, it loads OK
6. opening an old question with an image, it loads OK
7. log out (Chrome still open with private navigation)
8. the cookie is still set to visit=ABC (same as before)
9. login with google as user2 (different from before)
10. the cookie is still set to visit=ABC (same as before even after logging in with a different user)
11. creating a new question with an image, it FAILS to load
12. opening an old question with an image, it seems to load ok, but it is just cached. If I force reload without cache (Ctrl+Shift+R) the image FAILS to load

Let me know if you can replicate this behavior or if you need more details

[LinkinStars]

@Giorgio-Bonvicini-R4P Great! Your detailed steps helped.

We finally reproduced the problem. You were right. The problem was with the same cookie.

the cookie is still set to visit=XYZ (same as before, this is what looks suspicious to me)

After log out(step 7), the old cookie A will be ineffective. However, in the 8 step, since the previous cookie was not deleted, the new cookie was not set. So the old cookie was used to continue accessing the site, causing the problem.

I think the following modification may solve the problem.

answer/internal/controller/user_controller.go

Lines 719 to 723 in 3f1ed50

	func (uc *UserController) setVisitCookies(ctx *gin.Context, visitToken string, force bool) {
	cookie, err := ctx.Cookie(constant.UserVisitCookiesCacheKey)
	if err == nil && len(cookie) > 0 && !force {
	return
	}

- 	cookie, err := ctx.Cookie(constant.UserVisitCookiesCacheKey) 
- 	if err == nil && len(cookie) > 0 && !force { 
- 		return 
- 	} 
+	if !force {
+		cookie, _ := ctx.Cookie(constant.UserVisitCookiesCacheKey)
+		// If the cookie is the same as the visitToken, no need to set it again
+		if cookie == visitToken {
+			return
+		}
+	}

[Giorgio-Bonvicini-R4P]

Wow that was fast. Thank you so much for the effort!

However, I am having trouble testing your proposed change (pretty sure it's my fault this time 😝).

I am running everything in docker so what I tried to do this:

• git clone https://github.com/apache/answer.git
• applied the patch to internal/controller/user_controller.go
• docker build -t answer-hotfix:local . (compiles ok)
• moved to my docker compose folder
• changed the first row of my Dockerfile from

  FROM apache/answer as answer-builder
  

  to

  FROM answer-hotfix:local as answer-builder
  

• docker compose up -d --no-deps --build --force-recreate (compiles and starts ok)

However it looks like nothing changed: I tried adding and modifying some log.Infof calls to make sure I was running the correct version and, alas, I do not see them, so I guess it's somehow using the previous binary isntead of my modified one...

I will keep trying and if nothing else works in the weekend I will set up a development environment in a VM to test this.

Thank you again for the excellent support

[LinkinStars]

@Giorgio-Bonvicini-R4P

No need to build it twice.

• git clone https://github.com/apache/answer.git
• applied the patch to internal/controller/user_controller.go
• add your plugins in https://github.com/apache/answer/blob/main/script/plugin_list
• docker build -t answer-hotfix:local . (compiles ok)
• use the answer-hotfix:local image directly

[Giorgio-Bonvicini-R4P]

Just got to the same solution and... I can confirm I can no longer reproduce the bug!

[LinkinStars]

Just got to the same solution and... I can confirm I can no longer reproduce the bug!

If you've tested it and it's working fine, and you're willing to, you can submit a PR.

[Giorgio-Bonvicini-R4P]

Done: let me know if you need anything else from me, otherwise I will wait for the bugfix to hit release.

And thank you again for the excellent support: it was a pleasure working with you.