Getting HTTP 302 -> /403 on displaying uploaded images after answer "update"

[heubeck]

Describe the bug

Not sure when it started (maybe with 1.2.1 or after running 1.2.1 for some days, but not sure), and have no idea how to analyze the following issue:

Uploading images works well, they're written to the updates folder in the file system. But when displaying them, answer returns a HTTP 302 redirecting to /403.

Uploaded avatars and the brand image are still working.

There are no additional information in debug log, pardon me, I've no idea how to taggle this.

The installation is private, when changing it to public, images are shown. so it seems to be related to login session handling for images downloads.

To Reproduce

Steps to reproduce the behavior:

1. having a private answer
2. deploy a rebuild answer binary (answer build --with-plugins...)
3. uploaded images result int http 302 -> /403
4. clear cookie visit and reload page
5. uploaded images work again

Expected behavior

Uploaded images continue to being shown also after answer updates

Screenshots

If applicable, add screenshots or video to help explain your problem.

Platform

• Device: Any
• OS: Official answer container image
• Version: v1.2.1 --with-plugins

[LinkinStars]

@heubeck Let me confirm, is it the same question as this one? #667

[heubeck]

@heubeck Let me confirm, is it the same question as this one? #667

ahhh, you're right, @LinkinStars , pardon me.

regarding your checks from #667:

Confirm that the image url can be accessed directly from your browser.

no, also redirect to 403 page

Is there any error log output?

not a single line, even on debug level :(

and it definite worked with a unchanged setup on answer 1.2.0 before

[LinkinStars]

@heubeck I just tried my Answer and it is normal. So it should be the environment issues. Help me confirm two situations. Firstly, try re-login after setting private mode and uploading the image again. Second, check your browser's cookie about Answer to see if it's working.

[heubeck]

You're awesome, @LinkinStars Seemed to be some caching/session issue. using a clear browser-session solved the issue.

is there a way to force renewal of all sessions, so that other users don't run into this issue as well?

[LinkinStars]

Great!

is there a way to force renewal of all sessions, so that other users don't run into this issue as well?

I think maybe browsers generally have this feature to reload.

[heubeck]

I think maybe browsers generally have this feature to reload.

sure - just wondering, if it could be worth having it enforced from answer itself after an update for instance.

but if that issues isn't recurring, I've to excuse myself for expecting a bug rather than a client issue.

[LinkinStars]

I think maybe browsers generally have this feature to reload.

sure - just wondering, if it could be worth having it enforced from answer itself after an update for instance.

but if that issues isn't recurring, I've to excuse myself for expecting a bug rather than a client issue.

Yep. In fact, we should add a reminder that users need to re-login after turning on the privacy mode to ensure that the uploading of images functions properly. Re-login is actually what you say "force renewal of all session".

[heubeck]

Re-login is actually what you say "force renewal of all session".

that did not help in our case, can confirm, that other users hat the same issue, and only clearing the browser cache helped. even while private mode was enabled, newly uploaded images (and existing ones) could not be GET. re-login didn't help, only purging the entire browser cache.

a server restart with a new deployment (newly answer build --with-plugins with same versions) seemed to cause the issues. trying to reproduce it.

[heubeck]

ok, was able to reproduce:

• having a private answer
• deploy a rebuild answer binary (answer build --with-plugins...)
• uploaded images result int http 302 -> /403
• clear cookie visit and reload page
• uploaded images work again

[LinkinStars]

ok, was able to reproduce:

• having a private answer
• deploy a rebuild answer binary (answer build --with-plugins...)
• uploaded images result int http 302 -> /403
• clear cookie visit and reload page
• uploaded images work again

Thanks for the feedback. There are a few other questions I'd like to ask you. Sorry for the more questions, as I really didn't reproduce the problem following your steps. So I need your help.

1. Do you need to log in again after restarting with a new deployment? I want to make sure the cache is working properly.
2. If you don't restart is everything ok?
3. You're just using domain access right?
4. What browser are you using?

I think the key to the problem, as you describe it, would be in the cookie. 🤔

[heubeck]

no worries, really happy to help as answer is a really great project supported by a great team 🥰

Do you need to log in again after restarting with a new deployment? I want to make sure the cache is working properly.

yes, after the server restart, clients are logged out automatically

If you don't restart is everything ok?

yes, even restarts with an unchanged answer binary doesn't cause issues

You're just using domain access right?

what do you mean? Answer is accessed on a certain domain using the basic oauth connector as only login/registration method. private mode, so nothing but the "connect with ..." button visible for the public

What browser are you using?

tested with chrome and firefox, same behavior

[LinkinStars]

yes, after the server restart, clients are logged out automatically

In the configuration file, there is a file_path where the cached data is stored. The Answer caches the user's login information and puts it there. If you persist this file, it prevents from logout users after restart. However, I'm not sure if this is the cause. Just a guess. I am still looking into this issue.

[heubeck]

Tested it, can confirm, that keeping the cache doesn't logout users - and also, that the uploaded image access issue is gone.

That's a workaround, but I guess no final solution?