LFS Inconsitency with Authentication on Gitea &lt;1.9 #3477

@andrewgdunn commented on GitHub (Jun 16, 2019):

@lunny this is what you and I were talking about earlier.

@andrewgdunn commented on GitHub (Jun 16, 2019): @lunny this is what you and I were talking about earlier.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

@storrgie I tried to reproduce your exact steps on my own server on version 1.7.5 and it does not give the same errors, everything seems to work fine...
Test repos can be found at https://git.bryanpedini.it/bryanpedini/test and https://git.bryanpedini.it/School/test.

@bryanpedini commented on GitHub (Jun 16, 2019): @storrgie I tried to reproduce your exact steps on my own server on version 1.7.5 and it does not give the same errors, everything seems to work fine... Test repos can be found at https://git.bryanpedini.it/bryanpedini/test and https://git.bryanpedini.it/School/test.

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

I'll repeat, maybe the test procedure was confusing above:

create repo under user account
create repo under organization that you are the owner of
push lfs objects to both repos (should work)
clone repo from user account to another location on your client machine (should work)
clone repo from organization to another location on your client machine (get 401 authentication errors)

I am getting this on both of my instances, however both are 1.8.1.

@andrewgdunn commented on GitHub (Jun 16, 2019): I'll repeat, maybe the test procedure was confusing above: - create repo under user account - create repo under organization that you are the owner of - push lfs objects to both repos (should work) - clone repo from user account to another location on your client machine (should work) - clone repo from organization to another location on your client machine (get 401 authentication errors) I am getting this on both of my instances, however both are 1.8.1.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

create repo under user account

done

create repo under organization that you are the owner of

done

push lfs objects to both repos (should work)

done ( TXT files )

clone repo from user account to another location on your client machine (should work)

working without problems

clone repo from organization to another location on your client machine (get 401 authentication errors)

unexpectedly working without problems, you can test yourself cloning with the two repos I linkes.

IDK, maybe it's 1.7.5 that does not have this issue...

@bryanpedini commented on GitHub (Jun 16, 2019): > create repo under user account done > create repo under organization that you are the owner of done > push lfs objects to both repos (should work) done ( TXT files ) > clone repo from user account to another location on your client machine (should work) working without problems > clone repo from organization to another location on your client machine (get 401 authentication errors) unexpectedly working without problems, you can test yourself cloning with the two repos I linkes. IDK, maybe it's 1.7.5 that does not have this issue...

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

It might be, I remember doing some testing of LFS in the late 1.7.x run before turning it on, now I'm trying to use it and it seems to be biting me. It could also be configuration, but I shared configurations with @lunny for him to review and we were both stumped.

@andrewgdunn commented on GitHub (Jun 16, 2019): It might be, I remember doing some testing of LFS in the late 1.7.x run before turning it on, now I'm trying to use it and it seems to be biting me. It could also be configuration, but I shared configurations with @lunny for him to review and we were both stumped.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Are both instances newly created ones?
Maybe try to recreate the issue with a quick test env installation from the gitea/gitea Docker Hub image or a quick VM with CentOS (lightweight enough) or Debian (also light) if you feel more comfortable with apt instead...

@bryanpedini commented on GitHub (Jun 16, 2019): Are both instances newly created ones? Maybe try to recreate the issue with a quick test env installation from the gitea/gitea Docker Hub image or a quick VM with CentOS (lightweight enough) or Debian (also light) if you feel more comfortable with apt instead...

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

I'm going to wait for someone to weigh in who is maintaining their test instance as I'd rather reproduce with the instance they are managing. I've already been able to reproduce this consistently on instances I deploy.

@andrewgdunn commented on GitHub (Jun 16, 2019): I'm going to wait for someone to weigh in who is maintaining their test instance as I'd rather reproduce with the instance they are managing. I've already been able to reproduce this consistently on instances I deploy.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Does the issue appears on https://try.gitea.io too?

@bryanpedini commented on GitHub (Jun 16, 2019): Does the issue appears on https://try.gitea.io too?

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

@andrewgdunn commented on GitHub (Jun 16, 2019): > I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

nope...
https://try.gitea.io/johifsdgjikhfsdjihfsaehjisdf_test_org/test - seems to be working... now IDRK...
(did the exact same steps you described), (cloning works too)

@bryanpedini commented on GitHub (Jun 16, 2019): > I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?) nope... https://try.gitea.io/johifsdgjikhfsdjihfsaehjisdf_test_org/test - seems to be working... now IDRK... (did the exact same steps you described), (cloning works too)

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ?

@lunny commented on GitHub (Jun 16, 2019): Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ?

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ?

AH...
okay... trying it now...

(perfect..... I registered an account with a fake email address and now have to wait 3 hours to registration to timeout to reuse the same username..... I'm a genius.....)

@bryanpedini commented on GitHub (Jun 16, 2019): > > > Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ? AH... okay... trying it now... (perfect..... I registered an account with a fake email address and now have to wait 3 hours to registration to timeout to reuse the same username..... I'm a genius.....)

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

Haven't told you that's need an email confirmation. It's a real site not a try site.

@lunny commented on GitHub (Jun 16, 2019): Haven't told you that's need an email confirmation. It's a real site not a try site.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Haven't told you that's need an email confirmation. It's a real site not a try site.

I figured that out by myself.... -.-
Could you delete instances for username "bryanpedini" on DB or resend a confirmation email at bryanpedini@bryanpedini.it please? (if you are maintainer there)?

@bryanpedini commented on GitHub (Jun 16, 2019): > > > Haven't told you that's need an email confirmation. It's a real site not a try site. I figured that out by myself.... -.- Could you delete instances for username "bryanpedini" on DB or resend a confirmation email at bryanpedini@bryanpedini.it please? (if you are maintainer there)?

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

I have deleted it.

@lunny commented on GitHub (Jun 16, 2019): I have deleted it.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Thanks!
Trying the bug now.

@bryanpedini commented on GitHub (Jun 16, 2019): Thanks! Trying the bug now.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Nope, bug not present here: https://gitea.com/bryanpedini_test_org/test_repo
Can push without problems,
Can re clone without problems...

@bryanpedini commented on GitHub (Jun 16, 2019): Nope, bug not present here: https://gitea.com/bryanpedini_test_org/test_repo Can push without problems, Can re clone without problems...

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ?

@lunny commented on GitHub (Jun 16, 2019): So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ?

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ?

Yeah.. idk, on 1.9.0dev issue is not present...

@bryanpedini commented on GitHub (Jun 16, 2019): > > > So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ? Yeah.. idk, on 1.9.0dev issue is not present...

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

someone of https://github.com/go-gitea/gitea/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+milestone%3A1.9.0+lfs

@lunny commented on GitHub (Jun 16, 2019): someone of https://github.com/go-gitea/gitea/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+milestone%3A1.9.0+lfs

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Did not say there weren't issues at all, I did say this particular one is not currently present on try.gitea.io and on gitea.com :P

@bryanpedini commented on GitHub (Jun 16, 2019): Did not say there weren't issues at all, I did say this particular one is not currently present on try.gitea.io and on gitea.com :P

GiteaMirror commented

@zeripath commented on GitHub (Jun 16, 2019):

@Bryanpedini #7082 should fix the last major one I know about - however fixing the problems the inverse of #732 has caused may need #7199 and some admin features.

I'm afraid that if you have successfully merged from a fork with LFS changes you can currently lose LFS stored data if you then delete the fork and don't LFS push to the base repo from a separate checkout.

@zeripath commented on GitHub (Jun 16, 2019): @Bryanpedini #7082 should fix the last major one I know about - however fixing the problems the inverse of #732 has caused may need #7199 and some admin features. I'm afraid that if you have successfully merged from a fork with LFS changes you can currently lose LFS stored data if you then delete the fork and don't LFS push to the base repo from a separate checkout.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

@zeripath I don't actually know what LFS is 😅
I was just the betatester man for the issue the OP has brought out...

@bryanpedini commented on GitHub (Jun 16, 2019): @zeripath I don't actually know what LFS is 😅 I was just the betatester man for the issue the OP has brought out...

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

I am unable to reproduce the same issue on gitea.com:

My test sequence was:

clone repository
git lfs install
git lfs track "*.jpg"
added the three files
git add .
git lfs ls-files (confirm lfs is tracking these three images)
git commit
git push

then I was able to clone these repositories to another area on my client, and from a second client.

So the version running on gitea.com may resolve this issue. I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there. Also @Bryanpedini I'm not sure you're doing the same thing that I am doing (are you positive that lfs is uploading objects?), when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine.

@andrewgdunn commented on GitHub (Jun 16, 2019): I am unable to reproduce the same issue on gitea.com: - https://gitea.com/storrgie/testinglfs - https://gitea.com/epiphyte/testinglfs My test sequence was: - clone repository - `git lfs install` - `git lfs track "*.jpg"` - added the three files - `git add .` - `git lfs ls-files` (confirm lfs is tracking these three images) - `git commit` - `git push` then I was able to clone these repositories to another area on my client, and from a second client. So the version running on gitea.com may resolve this issue. I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there. Also @Bryanpedini I'm not sure you're doing the same thing that I am doing (are you positive that lfs is uploading objects?), when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine.

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

Also @Bryanpedini I'm not sure you're doing the same thing that I am doing.

Yes, same exact commands (except for git lfs ls-files) which, if there are three files in the repository after pushing, I expect that to be working. Tell me if I'm wrong here.

when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine.

I didn't actually say that LFS was disabled on try.gitea.io ... @lunny did, in fact he gave me the suggestion to try the same things out on gitea.com ... I only tried the same steps over and over and over and over on my website on my account, on my website in an organization, on try.gitea.io in an org, and on gitea.com in an org, since your first problem seemed to be only with organizations' repositories...

I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there.

That's actually for an entire different reason that I want to upgrade... (see #7218)

@bryanpedini commented on GitHub (Jun 16, 2019): > Also @Bryanpedini I'm not sure you're doing the same thing that I am doing. Yes, same exact commands (except for `git lfs ls-files`) which, if there are three files in the repository after pushing, I expect that to be working. Tell me if I'm wrong here. > when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine. I didn't actually say that LFS was disabled on try.gitea.io ... @lunny did, in fact he gave me the suggestion to try the same things out on gitea.com ... I only tried the same steps over and over and over and over on my website on my account, on my website in an organization, on try.gitea.io in an org, and on gitea.com in an org, since your first problem seemed to be only with organizations' repositories... > I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there. That's actually for an entire different reason that I want to upgrade... (see #7218)

GiteaMirror commented

@andrewgdunn commented on GitHub (Jun 16, 2019):

@Bryanpedini were you doing all these operations over ssh or http? I would surmise that http is working but ssh isn't due to some pre-auth stuff with JWT not happening.

@andrewgdunn commented on GitHub (Jun 16, 2019): @Bryanpedini were you doing all these operations over ssh or http? I would surmise that http is working but ssh isn't due to some pre-auth stuff with JWT not happening.

GiteaMirror commented