-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
States don't seem to work properly anymore #77
Comments
Sorry, I can not reproduce the issue you report. Indeed the authentication strategy has been reimplemented shortly ago. So far I only had positive results on that modification. So I take your report seriously. @fredl99 : Can you provide any more details / info? Especially which browser you are using? |
Thanks for the reply, I'm currently trying with different browsers and will report asap. |
I have tried Google-Chrome, Iceweasel, Qupzilla and the Gnome-Browser (which afair is based on Epiphany). No matter what, it's the same behavior with all of these. When has the authentication strategy changed, may I ask? (commit?) |
This is the commit that reimplemented the authentication strategy: commit d023c6d The different is that the authentication strategy has been changed when an authentication is required. It uses basic http authentication now. This results in a separate modal authentication dialog displayed by the browser, not on the owncloud login dialog as before. This prevents some routing issues and is logically cleaner in my eyes. In the end such an access has nothing to do with using the shorty UI itself. I have no idea what the problem is in your case. |
It's always the same, regardless which browser or if I'm already authenticated or not. The "Forbidden" message comes immediately, except when the Shorty is "public". I've reverted to the commit just before the introduction of HTTP auth, and it's the same. So it doesn't look like shorty's fault, but in my server config. Funny that it works with public shortys. Apart from that it would look like trying to get a directory listing, which is of course "Forbidden". That would mean it's using a wrong path, but not with public shortys. Hmm.. |
https insecure element warning is tracked separately in issue #87 now. |
This sounds like you are using the static backend and configured it such that it points to the folder your owncloud installation is located in. That indeed will not work. |
Hm... maybe such configuration should be prevented in an explicit manner. |
Correct.
Well, I was heavily relying on the randomness of shorty-ids and the correct behavoiur of OC-files and folders just in case. But basically you're right, I will re-configure with this in mind. Thanks for the hint!
"Make it fool-proof and a better fool will come along." 😃 |
I separated the issue of the backend configuration in to issue #89. Feel free to reopen this issue if reconfiguring the setup does not solve your problem :-) |
BTW: the Shorty IDs are not random at all! and that is important! |
I'm afraid my problem continues to exist. Tried several variations, but the result is always a "Forbidden" message, when it should work logically. While Shortys directly within the OC dir might have been a questionable idea, that alone doesn't seem to be the cause. I've tried shortys directly under doc-root as well as with non-existent sub-dirs, always with according rewrite-rules. No luck. BTW: I took precautions against collisions with existing files/folders. One of them was a sort of "salt" by preceding the Common facts:
|
OK, that brings us forth a step!
Whatever. In both cases best would be to take a look at the log files. Not sure if you have access.
Any entries there during a request? |
Since "public" Shortys work instantly, the service must be accessible and the request is resolved. The only difference is when the state is any other than public. The logs don't show any useful entries. Only errors when resolution fails due to improper rewrite-rules. Interestingly enough there's no logging of succesful access, either. Also no 40x-errors, which would make sense if http-auth takes place. BTW: Can you catch this page here with the shortlet? The URL field is flashing, until I remove or escape the |
Well, there must be a log entry in the access log file about the request. Otherwise you really have an issue with your system :-) Most likely there are no 40x errors in the log files because the error is not created by the http server, but by the app. There most likely is an easy solution for this, but I don't see it right now with the limited information I have. This might very well be a bug, so I take this serious. But I haven't got a clue. Could you grant me access to your system somehow? Temporarily? I know.... that is always a problem. But we have to dig deeper here... I re-checked the code again. The strategy is this: a 403 is thrown for all states expect public. This matches this issue. The purpose of the 403 is that that the browser retries the request after having asked for authentication credentials. This, because it received according http headers asking for authentication. Sorry, too tired right now, tomorrow is another day. Oh: happy new year :-) BTW: I have no problems at all with the link you mention. I can use it, create a Shorty for it, using the Shortlet or pasting it directly. There is no flashing going on and the target is called when accessing the Shorty. |
Happy New Year to you and family, too!
I was wondering all the time, why tail -f is so silent. Then I read this. Now it's clear. No useful debugging possible that way. I have requested error-logging now. This should help. It's not a question of trust, but I guess at the moment you wouldn't see more than I on the server. I can find a lot of 40x codes in the recent log, but it's hours old. I have to tidy up my list of shortys to regain some overview. My list is full of differently created id's from the last experiments. Will have to start over then. The owncloud.log is running continous, but there are only creations logged and script errors due to invalid id's. Thank you for the explanations, I will look at this on the weekend. |
Hm... "script errors due to invalid id's"... might be interesting to take a closer look here. Are those Shorty IDs or something else? But in the end more interesting would be to step through the relay code and see what's happening. Either using a debugger or at least using debug output steps. |
The invalid IDs were caused by different configuration variants. When I changed the path, the formerly created IDs became invalid. Hence the errors. The "Forbidden" message is in a typical owncloud screen. Here's a log entry from a "shared" shorty:
That's interesting: There's not even one 401-code created by shorty. But from BTW: Wikipedia says about 403: "Die Anfrage wurde mangels Berechtigung des Clients nicht durchgeführt. Diese Entscheidung wurde – anders als im Fall des Statuscodes 401 – unabhängig von Authentifizierungsinformationen getroffen, auch etwa wenn eine als HTTPS konfigurierte URL nur mit HTTP aufgerufen wurde." |
OK, that makes some sense. If requests to Shortys defined in older configurations are not rewritten correctly any more, then it is not Shortys relay handler that is called with the correct Shorty ID, but something else, typically something undefined, which might well result in a forbiddden error in ownCloud. In taht case the effect is not caused by Shorty. So in my eyes this has nothing to do with Shorty, nor with http/https which works fine for me. What I'd like to know now: what with freshly generated Shortys using a correctly configured static backend. Same behaviour? Then my first guess would be that the configuration is not correct. Two ways to tell:
|
Does that mean short URLS should be re-created when the base-url changes? There should't be any shorties with, say Neither old nor new shortys work. The old ones have obsolete IDs, so they cannot work. New ones only work when they're "public". All, old and new relay-URLs work, but only if they're public. And that's what confusing me here. Why would these work when your theory is right? The testing tool does not succeed. I haven't noticed that until now, because it always took a while until it finished. My guess is, all these problems came in with the update from 7.0.3 -> 7.0.4. It definately worked with 7.0.3, but reverting back did not help. So what would be a death-proof setup to start all over in your opinion? |
Ok, did some further investigations 🚶 What we have:
To me there are two things obvious now:
|
@arkascha could you please re-open this issue? I don't have that option. |
You are obviously right, that some of the 403s are completely wrong. Anyways, I made some changes that look better to me, but unfortunately I currently do not have time to test that as required. Do you want to give it a try? This would also have another advantage: you could give it a try and make such changes yourself, if you want to. I'd be happy to grant you write access! :-) |
Ok, @arkascha |
To keep things transparent always post and track issues at the "offical" repository. Since owncloud is an international project using English as communication language does make sense. On the other hand a German feedback or ticket is better that none :-) It is a very typical thing to use private repositories to prepare and evaluate spikes and bug fixes before merging them into the official repository. That allows to keep failed attempts out of the project history. |
I just thought to discuss things where they happen. But when it's common practice then naturally I will accept the rules. Back to topic: Of course I see that somehow it has to be decided if a client's request for a particular shorty is valid. But as a bottom line there are only three options:
In my opinion the HTTP-auth interferes with OC's auth, or am I missing something? |
First of all apologies for not replying and coding faster - another project requires my attention. About the authentication strategy: At the time of testing http authentication to an OC session was not possible. Or so I thought. There actually is an app that implements exactly that, because it is (was) missing in the OC core. But now indeed my short test indeed confirms your observation. This indeed is a problem... sigh |
I just pushed a reimplementation of the relaying strategy, authorization and forwarding aspects. @fredl99 Wanna give it another try? |
I just tried.
There is a login screen or not before, depending on the auth state. But the result is the same. |
ooops, sorry for that. Debug output statements that should not have been pushed. As said: work in progress. |
😄 OK! tested:
Aside from that: As always, well done! ➕ |
Fixed the issue about private Shortys. That indeed was a logical twist I implemented :-( |
@fredl99 OK, three issues left here:
|
Regarding the Umlauts, I only mentioned it here because it appeared on the new warning page. Of course it belongs to the other thread. Code 403 for a private Shorty makes sense, I agree. A also had the strange encoded address line withe the doubled directory name. First I thought about a wrong rewrite, but this couldn't alter the encoding. As it only happens during the login sequence, I think you're right. Pasting the correct link into the field again does work anyway, when the auth was successful before. |
OK, just talked to Lukas and he confirmed the issue with the scrambled redirection URL. @fredl99 I guess this means this one can be closed? |
Basically the initial issue seems resolved. So this long-term topic could be closed, yes. (I cannot do that, because you opened it.) I was just thinking if there could be a way out of the one-way street when a user logs in for a Shorty which isn't available to him. Because the "forbidden"-screen without any way out is not so cool. :) Of course that'll be a nice extra, but not a requirement. |
Closing for good... |
@fredl99 reported this issue in over there: #76
I took the liberty to separated the issue here into a separate entry.
The selected states don't seem to work properly anymore. Any of "closed", "private" or "shared" results in a "forbidden" message when calling the short URL, regardless if or which user is logged in. No login-page appears either. The only working status at the moment is "public".
The text was updated successfully, but these errors were encountered: