403 when previewing photo

[princemaple]

works when trying to preview/edit text file, though

[hacdias]

If it is 403 (forbidden), the problem should be on the permissions side. Could you tell me if there is any error on the Developers Tools (F12)?

I can't reproduce.

[princemaple]

An irrelevant minor bug, the download url /api/download//my_img.jpg?token=... has double slashes in it.
Removing which does not help. Just an FYI.

[princemaple]

console shows regular 403 error. no js error logged.

[hacdias]

You sure the file has the right permissions? Can you delete ir or rename it? Or you can't just preview?

[princemaple]

Just tried: can delete with no problem. Also, search gives 403 as well. There might be something wrong with the token sent in the js, or the parsing on the server side.

[hacdias]

Could you try logging out and logging in again to see if it works again?

[princemaple]

Could you try logging out and logging in again to see if it works again?

Still the same :(

[princemaple]

All failing (403) requests have the token in their params. That's why I made the deduction.

There might be something wrong with the token sent in the js, or the parsing on the server side.

[princemaple]

which isn't needed, because it's auth in the cookie anyway

[hacdias]

I think there isn't any problem with the token since you can delete (which needs the token to be sent too, but sends it in the HEADER instead of sending it in the URL).

The back-end is only looking for the Auth in the URL or the Header, but I think I should remove the URL and make it check the Cookie instead. It's better.

Anyway, to make sure if the problem is the token in the URL: please try downloading a TEXT file that you can edit. When you click the download button, it will also generate a URL that has the token in it and ping me 😄

Sorry for all of this

[princemaple]

Sorry for all of this

don't! that's a great plugin, and you are responding so fast!

Anyway, to make sure if the problem is the token in the URL: please try downloading a TEXT file that you can edit. When you click the download button, it will also generate a URL that has the token in it and ping me

403 (great advice!)

[hacdias]

Hmm... Indeed it must be the token in the URL, but I don't have that problem here 😭 Which is the browser you're using? FF?

[princemaple]

Yes FF :) proudly

[hacdias]

I just tried on FF too and I don't have that problem 😭 I'll remove this URL thing anyway and make it check the cookie though. Let's see what happens.

[princemaple]

I don't know much go but I couldn't find many occurrences of token in go code. Could you point me to where this logic is actually handled? Just for learning purpose :)

[hacdias]

This is where the token is extracted from the request: auth.go.

[hacdias]

I'm going to deploy this to the server now and I'll ping you when it is done so you can try again 😄

[princemaple]

Ok I thought it was an upstream bug, but I traced all the way back to http.Request (I assume is from go stdlib?) and couldn't see anything wrong, I don't know this language well enough. Well, that's all the effort I'm going to put into this.

[hacdias]

@princemaple, the newest build is already available to be downloaded from caddyserver.com 😄 Please tell me if it works

[princemaple]

I can see that the token is gone. However, I'm still getting 403s. Can you see anything wrong with my caddyfile in this issue?

[princemaple]

BTW username update is fixed, thanks!

[hacdias]

I really can't see any problem with your Caddyfile. The strangest thing is that it you receive a 403 error when previewing, but you can download, delete and rename the file, right?

And can you search and execute any commands?

[princemaple]

no I cannot download. delete and rename do work.

[princemaple]

and no I cannot search or execute commands, I tried git version, getting 403 as well.

[hacdias]

The thing is that this only happens with requests that don't send the token via Authorization header. Since I'm not being able to replicate this, I presume this is some problem with the system you're using.

If you're using Docker, could you just try running Caddy with File Manager outside of Docker, pointing to the same files and check if it works? Or try another folder with image files to see if it works, please.

This is so strange. I have to leave home right now, but I'll try to help you later and keep this issue in mind.

[princemaple]

Actually, I think I know why. For the requests that do FAIL, they are sending a basic token instead of a bearer token. Ring a bell?

[hacdias]

The most obvious problem would be permission issues, but since you can delete and rename, that must not be the problem. If the issue is really related to filemanager's source code, it must be related to the auth.

[hacdias]

Actually, I think I know why. For the requests that do FAIL, they are sending a basic token instead of a bearer token. Ring a bell?

The token is the same. But for the requests that FAIL it is sent via Cookie. The others send it via a specific HTTP header.

[hacdias]

Although, you had the same problem before, when I was passing it through the URL.

[princemaple]

Aha I'm correct
I edited the request to change the token from the basic token to the bearer token I got from another request, I successfully get the image back!

[princemaple]

Though I have no idea sending basic token instead would fail with a 403. Anyway, there's no need to save username and password locally if we have a jwt :) this should be made more secure.

[princemaple]

Are you storing username and password in the jwt? If so, this is the wrong approach to use JWT.
EDIT: I see you are not storing the password in it, great :)

[hacdias]

I haven't understood which basic token is that yet. I'm not storing the password in the JWT but I'm storing some user information on it so the front end knows what to show to the user.

…

On Wed, 19 Jul 2017 at 09:29, Po Chen ***@***.***> wrote: Are you storing username and password in the jwt? If so, this is the wrong approach to use JWT. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#143 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFMdsPLC5BxQFh8BmfIxzX6qoRRnzMemks5sPb5dgaJpZM4OcTOk> .

[hacdias]

Is that basic token something related to basic auth? : 😕

[princemaple]

yeah if you use basic token you are doing basic auth not jwt

[princemaple]

no it's not related to the basicauth config in my caddyfile though

[hacdias]

The thing I don't understand is why is your request sending a basic token since it was supposed to be sending the JWT one. Could you please check the value of "auth" cookie for that page?

[princemaple]

I see. My /manage route was under basicauth previously, I then took it out because now that it comes with its own auth system. However, the browser cached my basicauth token when I previously logged in, and is using it in requests that are not setting an Authorization header. I'm very sorry about this, wasting so much time of yours!

[princemaple]

This happens nowadays that people don't really restart browsers 😉 I tried a private session (which doesn't have records of my current session) and everything works as expected.

[princemaple]

My sincere apologies!

[hacdias]

No problem :) I'm glad it is solved 😀

…

On Wed, 19 Jul 2017 at 10:09, Po Chen ***@***.***> wrote: My sincere apologies! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#143 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFMdsKwPoFrCV17q15S45tL2VyhDfWr9ks5sPcfLgaJpZM4OcTOk> .

[hacdias]

Commit 503cc79 will prevent cases like this ;)