These are chat archives for go-gitea/gitea

25th
Jan 2017
Lunny Xiao
@lunny
Jan 25 2017 00:31
or we can give a config item to enable or disable oauth, default is enabled
renothing
@renothing
Jan 25 2017 02:17
implement by plugin better. keep core simple
related to website and github bountysource plugin
Thomas Boerger
@tboerger
Jan 25 2017 05:51
@lunny and what should happen than?
@renothing we don't have any plugin api yet
memory usage for unused Gitea in docker (Version: 1.0.0+133-gd2bb8ef5)
Thomas Boerger
@tboerger
Jan 25 2017 05:58
@metalmatze what does Prometheus say?
@tboerger are you asking me? :)
or no
Thomas Boerger
@tboerger
Jan 25 2017 06:02
No... This guy is watching gitea instance with Prometheus already quite long.
ok cool
I made #753 maybe it will be easier to discuss there
Willem van Dreumel
@willemvd
Jan 25 2017 07:09
@strk thanks! I will have a look at the UI changes, I’ve only added a simple green button with “Login with GitHub” ;)
@lunny if the admin is not configuring any OAuth provider, it will be automatically disabled ;)
Michael de Wit
@mjwwit
Jan 25 2017 07:13
are we going to make custom sources for a couple of well-known OAuth providers, or will there be a single "generic" OAuth login source?
Willem van Dreumel
@willemvd
Jan 25 2017 07:15
we use the https://github.com/markbates/goth library , and for now the only implemented provider is github
these goth libraries will be configured from 1 LoginOAuth2 source
it should now be quite easy to support different OAuth providers
Michael de Wit
@mjwwit
Jan 25 2017 07:24
cool
Willem van Dreumel
@willemvd
Jan 25 2017 07:25
(already building a openid connect provider for goth, so we can implement that as well)
Michael de Wit
@mjwwit
Jan 25 2017 07:37
does goth support provider specific features like GitHub orgs and Google Apps domains? Or will that require manual hacking?
Willem van Dreumel
@willemvd
Jan 25 2017 07:41
you can request additional scopes to get the orgs for example
but not sure if they will all end up in the goth.User.RawData field
Michael de Wit
@mjwwit
Jan 25 2017 08:54
I'm asking because a common feature for GitHub OAuth consumers is to allow the admin to set a filter on the allowed GitHub orgs
and the same goes for Google OAuth and google apps domain filter
Willem van Dreumel
@willemvd
Jan 25 2017 08:57
think we need to write custom code to get those extras
Thomas Boerger
@tboerger
Jan 25 2017 09:13
I think we don't need most scopes, we just need email and name / username
Willem van Dreumel
@willemvd
Jan 25 2017 09:13
for now the goth user setup should be enough
Thomas Boerger
@tboerger
Jan 25 2017 09:13
All the repos and so on we don't care about :)
Willem van Dreumel
@willemvd
Jan 25 2017 09:14
but the use case of @mjwwit is valid and probably a nice feature ;)
Michael de Wit
@mjwwit
Jan 25 2017 09:17
it should, however, be part of a different PR
Darren Bell
@KangoV
Jan 25 2017 09:17
We've started using Gitea in anger this week. Is branch security on the roadmap? This would include merging to master and merging pull requests.
Thomas Boerger
@tboerger
Jan 25 2017 09:18
@KangoV protected branches are part of 1.1
@willemvd @mjwwit yeah, limiting to specific orgs is another part we can integrate in a followup
Sandro Santilli
@strk
Jan 25 2017 09:20
"backport to v1.0 branch" <-- please try to make commit logs more useful (what does the patch do, beside being a backport, which can be written in the detailed description)
Darren Bell
@KangoV
Jan 25 2017 09:20
@tboerger Brilliant! Thanks. Feedback from our team is that they love Gitea. Keep up the good work. What's the timescale for 1.1?
Thomas Boerger
@tboerger
Jan 25 2017 09:24
@KangoV i think pretty soon. I’m pretty sure we will move various issues to 1.2.0
Sandro Santilli
@strk
Jan 25 2017 09:24
@willemvd: are you working on markbates/goth#120 ?
Willem van Dreumel
@willemvd
Jan 25 2017 09:30
@strk yes just submitted the PR for OpenID Connect support markbates/goth#127
Darren Bell
@KangoV
Jan 25 2017 09:33
@tboerger Thanks.
Sandro Santilli
@strk
Jan 25 2017 09:34
wow, and merged already ! :)
Darren Bell
@KangoV
Jan 25 2017 09:34
Can a webhook be set at the org level to notify Jenkins of a build? Are there any replacement parameters such as {repo} etc?
Sandro Santilli
@strk
Jan 25 2017 09:34
@willemvd: auto-discovery means I can login with an URL, right ?
I only used OpenID-2.0 so far (have my own provider) -- would gladly setup an OpenID-Connect provider if it lets me log into a Gitea instance :)
@willemvd: do you think I should deprecate my OpenID PR for Gitea and focus on an OpenID PR for goth ?
Willem van Dreumel
@willemvd
Jan 25 2017 09:38
that was a quick merge :P
@strk auto discovery means : get your info about the oauth urls, keys etc from 1 url like https://accounts.google.com/.well-known/openid-configuration
OpenID Connect follows the OAuth2 standard but can give you more details about the user from an id_token
Willem van Dreumel
@willemvd
Jan 25 2017 09:43
goth is about OAuth2 flows , so i’m not sure if OpenID will fit in
Sandro Santilli
@strk
Jan 25 2017 09:44
oh, didn't seem OAuth2 specific from the description
"provides a simple, clean, and idiomatic way to write authentication packages"
Willem van Dreumel
@willemvd
Jan 25 2017 09:45
well most of them follow OAuth2 flows, but guess others might fit in ;)
for your PR it might be a good idea to look at my gitea Oauth2 PR to see how I have handled that callback stuff
since you now have created a complete new login method
Sandro Santilli
@strk
Jan 25 2017 09:48
my first implementation made it into a LoginSource
but then I changed my mind about it as it was too much of an hack
implying a fake "Error" just to let callers be happy with the return
callers cascading over the list of configured sources, presenting username/password to each
for OpenID you don't have a username/password
and dunno if they are accepted until you get a callback
so wasn't really in the cascaded attempts logic currently used
what's your PR number to look at it ? "oauth" filter in PR doesn't find it
Willem van Dreumel
@willemvd
Jan 25 2017 09:50
go-gitea/gitea#679
will add a comment for github search on : oauth ;)
Sandro Santilli
@strk
Jan 25 2017 10:09
oh, it's github lameness, needs full word ("oauth2" matches)
Willem van Dreumel
@willemvd
Jan 25 2017 10:10
yep, stupid..
Sandro Santilli
@strk
Jan 25 2017 10:17
uhm, "gitea web" exists with error code 1 but doesn't print any interesting reason
from your branch, that is
oh, it's all in the logfile, nevermind
ok willemvd, I see the "sign in" screen with the new button
I really recommend you look at my openid then
there, the "sign in" page has a navigation bar on the left
one entry is "With username/password" and another is "With Openid"
you'd be adding a "With OAuth2" section
I think it'd be cleaner
and would allow for the same user to login using different credentials (an URL for OpenID, a username/password pair for direct login, an OAuth2 provider for OAuth2)
we probably want a 1:N table for different auths too (ie: multiple OpenID URIs - right now my branch has a single URI per user, adding a column to the user table)
Willem van Dreumel
@willemvd
Jan 25 2017 10:21
@bkcsoft @tboerger @lunny what is the way to go on the sign in page regarding adding new login methods? extra button below the sign in form like I did, navigation bar like @strk has implemented, or something else :)
Sandro Santilli
@strk
Jan 25 2017 10:21
btw, /user/oauth2/ 404 ( [E] GetUserByName: user does not exist )
to be honest @willemvd I'd also have preferred to get all methods inline on the same page, but was unable to figure how to make it nice looking :)
the navbar I copied from other places - let me upload a screenshot btw, as I guess it'd be easier for others to see
Thomas Boerger
@tboerger
Jan 25 2017 10:22
IMHO no navbar for oauth as we just need some button for each oauth source. but on the other hand it gets difficult to differentiate the oauth auth sources from the other auth sources
Sandro Santilli
@strk
Jan 25 2017 10:22
will screenshot yours too
Willem van Dreumel
@willemvd
Jan 25 2017 10:26
@strk how did you get that empty Login with button? :P
@willemvd: the oauth one is what I get by building, running and visiting (didn't touch the administration panel)
Willem van Dreumel
@willemvd
Jan 25 2017 10:29
@strk will have a look at that
Sandro Santilli
@strk
Jan 25 2017 10:30
see how you like the openid screens
Willem van Dreumel
@willemvd
Jan 25 2017 10:30
what is the diff between 1.png and 2.png?
Sandro Santilli
@strk
Jan 25 2017 10:30
ops
let me fix that
Michael de Wit
@mjwwit
Jan 25 2017 10:31
his mouse moved 3px to the left
Willem van Dreumel
@willemvd
Jan 25 2017 10:31
:)
Sandro Santilli
@strk
Jan 25 2017 10:31
done, please reload
so I'd imagine a third menu entry for OAuth2...
Willem van Dreumel
@willemvd
Jan 25 2017 10:32
for ppl like me how look at it inline : http://strk.kbt.io/tmp/gitea-signin-openid2.png
Thomas Boerger
@tboerger
Jan 25 2017 10:33
Adding another tab for oauth is insane because it will just be a button and nothing else
Willem van Dreumel
@willemvd
Jan 25 2017 10:33
who is good with frontend :P maybe 3 boxes that can be moved by the users to set a nice order for themself ?
Sandro Santilli
@strk
Jan 25 2017 10:34
and this is what you get after successful login: http://strk.kbt.io/tmp/gitea-signin-openid-connect-existing.png
Thomas Boerger
@tboerger
Jan 25 2017 10:34
@metalmatze you are a pretty good Frontend guy. What do you think about that?
Willem van Dreumel
@willemvd
Jan 25 2017 10:35
for now in my PR I will keep my button :P (but only when it should be there ofcourse :))
Sandro Santilli
@strk
Jan 25 2017 10:36
@willemvd: does the "Remember me" field apply to the OAuth2 login ?
Willem van Dreumel
@willemvd
Jan 25 2017 10:37
no
that is not needed with oauth, as long as you don’t logout, it will resume with the tokens as long as they are not expired
Thomas Boerger
@tboerger
Jan 25 2017 10:38
@willemvd most tools providing oauth just place one button per oauth provider below the login, so I think this should be totally fine
Willem van Dreumel
@willemvd
Jan 25 2017 10:39
@tboerger agree
Sandro Santilli
@strk
Jan 25 2017 10:40
I've also seen OpenID screens being done as single OpenID logo buttons as if it was an additional "provider", but then opening up a text input for you to enter your OpenID URI
Willem van Dreumel
@willemvd
Jan 25 2017 10:40
@strk sorry no when you close your browser, you will have to login again (but that should go without any additional steps then)
Lunny Xiao
@lunny
Jan 25 2017 10:41
@willemvd conflicted
Sandro Santilli
@strk
Jan 25 2017 10:41
@willemvd: no additional step for the user because the "remember me" mechanism would be done on his provider, right ?
Willem van Dreumel
@willemvd
Jan 25 2017 10:41
@strk yes
Sandro Santilli
@strk
Jan 25 2017 10:41
it's similar with OpenID, you can tell the OID provider to always send the required info to the specified url
so you as the user decide that
but the "Remember me" in Gitea is for a Gitea-specific cookie, which would be lost if not implemented
Willem van Dreumel
@willemvd
Jan 25 2017 10:42
@lunny will sync with master again
Sandro Santilli
@strk
Jan 25 2017 10:42
(that part also I didnt' implement yet for OID)
Willem van Dreumel
@willemvd
Jan 25 2017 10:42
not sure if you want “remember me” on the oauth login ?
in general I mean :)
Lunny Xiao
@lunny
Jan 25 2017 10:43
I will pull the PR and test it at first. :smile:
Michael de Wit
@mjwwit
Jan 25 2017 10:43
the "remember me" is taken care of by the OAuth provider right?
Willem van Dreumel
@willemvd
Jan 25 2017 10:43
@lunny @strk just found a small issue , so let me check that first
Michael de Wit
@mjwwit
Jan 25 2017 10:44
as long as you're logged in there
Willem van Dreumel
@willemvd
Jan 25 2017 10:44
@mjwwit yes
but you still need to hit that login button when entering gitea
Michael de Wit
@mjwwit
Jan 25 2017 10:45
hmmm, then I think we still need a cookie to indicate that Gitea should check the OAuth provider for an active session and log you in automatically if there is one
no OAUth consuming app I know of requires you to hammer the login button every time you re-open a browser
but this is another enhancement ofc, let's get this PR merged first
Willem van Dreumel
@willemvd
Jan 25 2017 10:48
@strk did you do a checkout of my PR before? cannot reproduce even when I delete my OAuth provider
(after changes in the .tmpl files, I always need to build twice in Gogland to get everything right…annoying)
Sandro Santilli
@strk
Jan 25 2017 10:58
@willemvd: no, but I might have a traces of my older OpenID implementation, which used to register self as a login-source (if that could affect things)
@mjwwit: the provider will remember you (or not), the consumer "remember" state is a separate thing
agreed on going there incrementally, anyway :)
Michael de Wit
@mjwwit
Jan 25 2017 10:59
@strk, but in this case, the consumer should only remember to check the provider session
Sandro Santilli
@strk
Jan 25 2017 11:00
uhm, not sure I follow. Why is that ? What happens if you login as a normal user and then your user is removed from db ?
strk @strk guesses the cookie is made invalid on the server side...
Sandro Santilli
@strk
Jan 25 2017 11:01
this cannot be done with external source as you dunno that a user was removed, is this the issu e?
would be the same with LDAP, right ?
Michael de Wit
@mjwwit
Jan 25 2017 11:02
here's the thing, if you remember your entire session after logging in with OAuth, Gitea will automatically restore your session. Gitea will even restore the session if you ended your session with the OAuth provider, this is not desirable for obvious reasons.
Sandro Santilli
@strk
Jan 25 2017 11:04
it's not obvious to me that you dont' want that
or it should check on every single request
(you might have ended the session with the OAuth provider while still using Gitea...)
Michael de Wit
@mjwwit
Jan 25 2017 11:05
you might, yes, but this will introduce a ton of overhead
I think it's acceptable if Gitea checks it when you open a new browser
Sandro Santilli
@strk
Jan 25 2017 11:07
gitea doesn't know if you open a new browser or not, only knows if you have a cookie or not. You're saying to inject a "remembered" cookie with just the OAuth identity and a "non-remembered" one with the Session ID ?
so that the OAuth identity cookie would automatically go checking and the other would not even check but stay logged
Michael de Wit
@mjwwit
Jan 25 2017 11:10
yes
this ensures that if the OAuth provider allows a user to "end all sessions", Gitea will logout when it checks the cookie
or if you delete your OAuth provider account, you will logout as well
Sandro Santilli
@strk
Jan 25 2017 11:12
is this mechanism used for LDAP ?
or SMTP
Michael de Wit
@mjwwit
Jan 25 2017 11:12
no idea, haven't used LDAP or SMTP auth with Gitea
Sandro Santilli
@strk
Jan 25 2017 11:12
I've used LDAP but not SMTP, guess it could be checked in code if it does it or not
Michael de Wit
@mjwwit
Jan 25 2017 11:13
but it's what I, as a user, would expect to happen if I "end all sessions" on the OAuth provider control panel
also, if you remove your OAuth provider account, you should be able to get a local Gitea account using the "forgot password" flow
Mark Larah
@mark_larah_twitter
Jan 25 2017 11:14
Hey there, is an API endpoint to create a repo? Or can I do this through SSH? Or even just by creating a new git directory in /data and syncing the db somehow? Had difficulty finding documentation on this in either gogits or gitea. Thanks! :)
Sandro Santilli
@strk
Jan 25 2017 11:15
@mjwwit: that's a great idea, the "forgot password" flow. I think it would work as long as your email is still valid
for the OpenID PR you get a record in the user table so it should work (didn't test it)
Thomas Boerger
@tboerger
Jan 25 2017 11:18
@mark_larah_twitter there should be an api endpoint for that
was it verified that the docs website looked okay 2 months ago when bootstrap 3->4?
Mark Larah
@mark_larah_twitter
Jan 25 2017 11:19
@tboerger yep indeed I just found it :)
I didn't click on the sidebar links :-1:
anyway thanks!
Thomas Boerger
@tboerger
Jan 25 2017 11:21
@jmn it looked ok with bootstrap4 beta5, like it’s referenced at https://github.com/go-gitea/theme/blob/master/package.json#L26, but the version constraint is not explicit enough so now it’s building with beta6 which seems to be broken because of various bootstrap changes.
really. that's interesting. I'll try lock it down and build it
Thomas Boerger
@tboerger
Jan 25 2017 11:22
i’m pretty sure that this is the case as beta5 looked totally fine
I tested it locally, it's like you thought. I made a PR go-gitea/theme#32
Sandro Santilli
@strk
Jan 25 2017 11:33
@willemvd: so you added a "login source" for Oauth2. Now this goes in the "user" table, right ?
user.login_source
binding each user to 1 and 1-only "login source"
you see it's still an hack to do that, for Oauth2
Michael de Wit
@mjwwit
Jan 25 2017 11:44
it definitely is
we should keep track of the login sources per user
but it should not be a 1-1 relation
Sandro Santilli
@strk
Jan 25 2017 11:44
sources
agreed
I think the reason for a 1-1 relation is for the username/password mechanism
rather than cascading, you'd be only checking the registered service (based on username)
Thomas Boerger
@tboerger
Jan 25 2017 11:45
@jmn the docs should be fixed in a few minutes
Michael de Wit
@mjwwit
Jan 25 2017 11:45
@strk, yeah
Sandro Santilli
@strk
Jan 25 2017 11:45
but only works when all auth methods are username/password based
so we should drop that
Michael de Wit
@mjwwit
Jan 25 2017 11:46
I think this is what @bkcsoft meant when he said the auth system needs a refactor
Sandro Santilli
@strk
Jan 25 2017 11:46
or, it would still be valid for "username/password" based logins
@tboerger cool. the build pipeline deletes and installs npm packages right?
Sandro Santilli
@strk
Jan 25 2017 11:46
which is the rationale for my "user/password" tab in my sign-in form (btw I've attached screenshots on the OpenID PR)
so user/password would still use the same mechanism
and upon sign-in the user has option to login with other mechanisms too (say OpenID or OAuth2...)
ideally having the ability (when enabled) to associate multiple such credentials to his user
1-N
so you need a "connect" page to associate your new login to existing user
in case you logged in with a still-unknown credential/method
Thomas Boerger
@tboerger
Jan 25 2017 11:49
@jmn currently there is no cache within the pipeline, so it always installs the best match for the constraints
@tboerger okay great :-)
Thomas Boerger
@tboerger
Jan 25 2017 11:50
now it’s just the question when the container gets restarted and when the cdn gets outdated :)
or someone could press the button? :D
Michael de Wit
@mjwwit
Jan 25 2017 11:51
@strk yes, but not just connecting, managing connections too. These external connections should be removable by the user as well.
for the CDN cache
maybe you'd want the pipeline to let the CDN know to reload cache
Michael de Wit
@mjwwit
Jan 25 2017 11:52
@strk and you should be able to register using an external provider (be it OpenID, OAuth, whatever-they-come-up-with-next)
Sandro Santilli
@strk
Jan 25 2017 11:52
@mjwwit: agreed, user should be able to add/remove openid/oauth2 thing
@mjwwit: yes, I have that in place already for OID too (the form, not much else :)
the registration phase should also depend on whether or not registration is active...
Michael de Wit
@mjwwit
Jan 25 2017 11:53
that's a good point actually
Sandro Santilli
@strk
Jan 25 2017 11:53
able-to-register is pretty much what already happens with the cascading login thing, btw
ie, we use LDAP
a user who isn't known yet, get automatically registered
(record added to user table)
Michael de Wit
@mjwwit
Jan 25 2017 11:54
I do see a use case where an admin would want to disable normal free-form registration, but enable registration through external providers like OID or OAuth
Sandro Santilli
@strk
Jan 25 2017 11:55
could be, yes, although given we need a "user" record anyway I'm not sure why would someone want to do that (at the moment)
maybe because the admin configures the external providers with filters
Michael de Wit
@mjwwit
Jan 25 2017 11:55
exactly
GitHub org filter, Google Apps domain filter, etc.
Sandro Santilli
@strk
Jan 25 2017 11:55
so he knows it'll only allow github, or OpenID uris from .edu domains (random crazy thing to do :)
what is considered reasonable memory usage for a low usage <10 user gitea deployment by the way? in round numbers
Michael de Wit
@mjwwit
Jan 25 2017 11:56
50MB
wow. OK thanks
Michael de Wit
@mjwwit
Jan 25 2017 11:56
at least, that's what my 8 user instance reports
Sandro Santilli
@strk
Jan 25 2017 11:57
my ~80 users is currently using ~30MB
(reported from admin panel)
2 weeks uptime
almost 3
and, it's Gogs
that's reassuring
Michael de Wit
@mjwwit
Jan 25 2017 11:59
there you go, Gitea is fucking glorious :sunglasses:
Sandro Santilli
@strk
Jan 25 2017 11:59
what's the difference between "Current Heap Usage" and "Heap Memory In Use", btw ? I have 29MB and 35MB respectively
top reports 2.8G virtual, 160M RES
the docker image I use, is using busybox. I think it maay have memory leaks
Sandro Santilli
@strk
Jan 25 2017 12:02
interesting, there's a "0 social accounts" mention in the "Statistics" section, must be related to that 2015-removed OAuth support
@willemvd: I just checked, indeed I have a record in the "login_source" table which is a leftover from openid
with type=6 - I bet it's your OAuth2 type... will clean it up
note that the cfg was an empty config, in case you want to handle that more gracefully in code
id | type | name | is_actived | cfg | created_unix | updated_unix
----+------+--------+------------+-----+--------------+--------------
1 | 6 | openid | t | {} | 1481387806 | 1481387806
it's good to be as graceful as possible even in presence of database corruptions like this :
Sandro Santilli
@strk
Jan 25 2017 12:07
how do I obtain a client-id/client-secret for use with the GitHub auth method ?
it'd be nice to have tips for that too (like there are tips for GMail usage at the bottom of the "Add New Source" page for login sources)
@lunny updated the PR to fix the merge conflict
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
0s
6
fatal: The remote end hung up unexpectedly
0s
7
exit status 128
and restart seems not to be working
@strk callback url is <host>/user/oauth2/github/callback
@strk @mjwwit user login_source is indeed 1-1 relation , think that should indeed be changed later on
Sandro Santilli
@strk
Jan 25 2017 12:14
where "github" is the "OAuth2 provider" name as selected, right ? (also useful to mention)
Willem van Dreumel
@willemvd
Jan 25 2017 12:14
no
fixed name
Sandro Santilli
@strk
Jan 25 2017 12:15
error=redirect_uri_mismatch
upon hitting the "Sign in", must have done it wrong (or cannot be used for names I can only resolve myself?)
sorry I dont' really know how OAuth2 works, does github need to be able to reach my Gitea deploy ?
Willem van Dreumel
@willemvd
Jan 25 2017 12:16
no i does a browser redirect
Sandro Santilli
@strk
Jan 25 2017 12:17
so this should work, right ? http://localhost:3000/oauth2/github/callback
missing that /user part
Sandro Santilli
@strk
Jan 25 2017 12:17
ah, great
so it also matches the /user/openid prefix :)
do any of you use gitea w/ docker? if so what is the memory usage of the vm
Sandro Santilli
@strk
Jan 25 2017 12:18
ok http response is 500 now, upon going to callback
[Macaron] 2017-01-25 13:18:40: Completed /user/oauth2/github/callback?code=1c5518e83380ae15b845&state=343448d6-43c2-47cc-8541-85b3253bcf09 500 Internal Server Error in 1.293143092s
Michael de Wit
@mjwwit
Jan 25 2017 12:19
@jmn I do
Sandro Santilli
@strk
Jan 25 2017 12:19
no more detail
Thomas Boerger
@tboerger
Jan 25 2017 12:19
try.gitea.io is running in docker
Michael de Wit
@mjwwit
Jan 25 2017 12:19
my cAdvisor reports the container uses ~50MB
which image?
Michael de Wit
@mjwwit
Jan 25 2017 12:20
1.0.1
Thomas Boerger
@tboerger
Jan 25 2017 12:20
our official image
ok thank you!
Thomas Boerger
@tboerger
Jan 25 2017 12:20
try.gitea.io is running :master
Michael de Wit
@mjwwit
Jan 25 2017 12:21
Docker containers are not VMs btw :wink:
yeah the correct term eluded me
Thomas Boerger
@tboerger
Jan 25 2017 12:21
ah latest and not master
Willem van Dreumel
@willemvd
Jan 25 2017 12:21
@strk nothing in the log file?
Sandro Santilli
@strk
Jan 25 2017 12:22
uhm, maybe 2017/01/25 13:20:31 [...routers/user/auth.go:359 SignInOAuthCallback()] [E] UserSignIn: no provider for github exists
and maybe this: 2017/01/25 13:18:40 [...routers/user/auth.go:359 SignInOAuthCallback()] [E] UserSignIn: user already exists [name: strk]
which calls for the "connect existing user" dialog...
@willemvd: ^
Thomas Boerger
@tboerger
Jan 25 2017 12:23
https://cl.ly/0Q1E0J1y3r1h htop in the try.gitea.io server :)
3b360b85c756 gitea/gitea:latest "/usr/bin/entrypoi..." 21 hours ago Up 21 hours 0.0.0.0:22->22/tcp, 3000/tcp demo
Michael de Wit
@mjwwit
Jan 25 2017 12:24
hehe
Bildschirmfoto
gotta love german
Thomas Boerger
@tboerger
Jan 25 2017 12:24
pretty similar in various places to dutch :P
Willem van Dreumel
@willemvd
Jan 25 2017 12:24
lol
Michael de Wit
@mjwwit
Jan 25 2017 12:24
yep
Willem van Dreumel
@willemvd
Jan 25 2017 12:25
totally true
Thomas Boerger
@tboerger
Jan 25 2017 12:25
especially lower german
plattdeutsch
mostly spoken nearby the border to nl :P
Willem van Dreumel
@willemvd
Jan 25 2017 12:26
haha wiki: Niederdeutsch oder Plattdeutsch :)
Michael de Wit
@mjwwit
Jan 25 2017 12:26
same shit the dutch folk speak near the german border then, can't make heads or tails of it
Thomas Boerger
@tboerger
Jan 25 2017 12:27
hehe
Willem van Dreumel
@willemvd
Jan 25 2017 12:27
@mjwwit especially “limbo’s “ ;)
Thomas Boerger
@tboerger
Jan 25 2017 12:27
but the germans are getting to nl anyway just to visit coffee shops haha
Willem van Dreumel
@willemvd
Jan 25 2017 12:28
and shopping malls on sunday..
Thomas Boerger
@tboerger
Jan 25 2017 12:28
:P
Michael de Wit
@mjwwit
Jan 25 2017 12:28
@willemvd that's because limbabwe really is a different country
Willem van Dreumel
@willemvd
Jan 25 2017 12:28
@strk what are you doing :P
:+1:
Sandro Santilli
@strk
Jan 25 2017 12:30
https://try.gogs.io/strk | https://try.gitea.io/strk | spot the difference: avatar in gitea profile doesn't show up for me (timeout)
Gitlab is a dutch-based company I hear
hollandaise
Willem van Dreumel
@willemvd
Jan 25 2017 12:31
@strk I can see you
Sandro Santilli
@strk
Jan 25 2017 12:31
@willemvd: I created a login source, then I tried "login with GitHub" and am redirected to the 500 page
Willem van Dreumel
@willemvd
Jan 25 2017 12:31
on both places
Thomas Boerger
@tboerger
Jan 25 2017 12:31
loading fine for me
Sandro Santilli
@strk
Jan 25 2017 12:31
@willemvd: now me too.
the difference now is in the "Gravatar" logo (only shown on the avatar served by gravatar) - try.gogs.io is serving my DNS specified avatar... (libre avatar, federated by default)
Willem van Dreumel
@willemvd
Jan 25 2017 12:33

@jmn : A brief history of GitLab
2011: Start of GitLab
In 2011 Dmitriy was unsatisfied with the options for git repository management. So together with Valery, he started to build GitLab as a solution for this.

This commit was the very start of GitLab.

Thomas Boerger
@tboerger
Jan 25 2017 12:33
¯_(ツ)_/¯
Willem van Dreumel
@willemvd
Jan 25 2017 12:33
Dmitriy sound more like Russian or East European
;)
@strk there should be some logging...
Thomas Boerger
@tboerger
Jan 25 2017 12:34
i followed gitlab in the really early days… as i have been also a rails devolpoer at that point in time :P
Sandro Santilli
@strk
Jan 25 2017 12:35
@willemvd: logging was "user strk already exists" (I do have a "strk" user already)
@willemvd: user "strk" with the simple login_source (username/password) exists
is that something you tested ?
Willem van Dreumel
@willemvd
Jan 25 2017 12:37
@strk think that is something we need to think about, how to handle this case
missed that in my clean setup
Sandro Santilli
@strk
Jan 25 2017 12:37
I gave it a thought as it's the same with OpenID
what I do is show that "connect with existing user" page
which asks you for the password, basically
Thomas Boerger
@tboerger
Jan 25 2017 12:38
@willemvd we should also be able to link oauth accounts against existing accounts :)
Willem van Dreumel
@willemvd
Jan 25 2017 12:38
let me try to fix that
Sandro Santilli
@strk
Jan 25 2017 12:38
and if password also matches, sets the "openid" field to your record
but I guess you might just be "another 'strk'", in which case maybe you want to re-map your nickname ?
that situation I didn't handle
Willem van Dreumel
@willemvd
Jan 25 2017 12:39
do we already have a page requesting for the password only?
Sandro Santilli
@strk
Jan 25 2017 12:39
I don't think so, I made my own (take a look at the screenshots)
oh wait, in my screenshot I'm also asking for a username
and never using the oid-reported username, looks like, if not as a default value
Willem van Dreumel
@willemvd
Jan 25 2017 12:44
@strk added this text as Tip on the new auth page:
v

OAuth GitHub:

Register a new OAuth application on https://github.com/settings/applications/new and use <host>/user/oauth2/github/callback as "Authorization callback URL"

Willem van Dreumel
@willemvd
Jan 25 2017 12:56
when attaching oauth to some existing user, should we change the authentication source from Local to <oauth loginsource name> or keep it as is?
Michael de Wit
@mjwwit
Jan 25 2017 12:58
I think we should keep it, as it indicates what source should be used when username/password auth flow is started
Willem van Dreumel
@willemvd
Jan 25 2017 12:59
oauth source can also use username/password auth flow when a password is set
(also needed for git over http)
Michael de Wit
@mjwwit
Jan 25 2017 12:59
yes ofc, but then OAuth will have nothing to do with it
the normal username/password flow should be used
but keeping the current loginsource for the user will allow OAuth to be combined with LDAP/SMTP
(I hope)
Willem van Dreumel
@willemvd
Jan 25 2017 13:01
true.. i guess..
Michael de Wit
@mjwwit
Jan 25 2017 13:01
so we'll end up with 2 types of auth, both have multiple sources
one is for username/password flows
the other for an external provider flow (OID, OAuth)
the username/password flow source will have a 1-1 relation to a user
since Gitea will need to know where to send the credentials after it receives them
Willem van Dreumel
@willemvd
Jan 25 2017 13:05
guess we will have a problem then , how do we set that extra loginsource on the user? that is not possible now, so we cannot persist the fact the user wants to attach it’s oauth
Michael de Wit
@mjwwit
Jan 25 2017 13:06
we will need a new link between external_login_source (or something similar) and user
this will be a N-1 relation
can we get away with not storing the oauth login source for the user for now?
I guess we can right? except for the fact that you need to hammer the login button every time you open gitea in a new browser
matrixbot
@matrixbot
Jan 25 2017 13:08
unlmtd testing, can you copy me?
Michael de Wit
@mjwwit
Jan 25 2017 13:09
yeah, works
Willem van Dreumel
@willemvd
Jan 25 2017 13:16
without storing the oauth login source, there will be no user when it is not present in the current user set
for existing users , if we won’t register it the user must enter it’s password every time
so useless
Michael de Wit
@mjwwit
Jan 25 2017 13:19
ah, yeah, ofc
Willem van Dreumel
@willemvd
Jan 25 2017 13:20
if we convert the user we dont have that problem, but that will only work for plain users not SMTP, LDAP (other oauth providers in the future)
Michael de Wit
@mjwwit
Jan 25 2017 13:20
indeed
so are we OK with possibly clearing and breaking LDAP/SMTP setups (for now)
Willem van Dreumel
@willemvd
Jan 25 2017 13:20
guess not :P
Michael de Wit
@mjwwit
Jan 25 2017 13:21
ugh, and here you were thinking that your PR was close to being done, haha
Willem van Dreumel
@willemvd
Jan 25 2017 13:22
….
Michael de Wit
@mjwwit
Jan 25 2017 13:24
this will be huge, we need to figure out a way to split it up
we'll need a db migration, a new ExternalLoginSource (or similar) model, and all the stuff you have done so far to integrate the oauth flow
maybe it's still doable without the management UI, other OAuth providers, Admin UI, and provider specific filters
Willem van Dreumel
@willemvd
Jan 25 2017 13:37
@tboerger any idea how to handle these cases? and how to store that data correct?
Sandro Santilli
@strk
Jan 25 2017 13:40
I agree about NOT changing the login_source
OAuth and OID have N-1 relation to user
in user settings, user need to be able to add/remove OID uris or OAuth2 <whatever-it-takes>
what I did for OID was just add a single column "OpenID_URI", but it falls short
anyway for OpenID it's a single method, doesn't have an attached configuration like OAuth2 seems to have
can OAuth2 identifications be reduced to simple strings like uris?
Michael de Wit
@mjwwit
Jan 25 2017 13:43
The settings UI part isn't required for @willemvd's PR IMO
Sandro Santilli
@strk
Jan 25 2017 13:43
possibly not, as I said I'm not used to OAuth2 flows
but you need to store an association between an external authentication and a local user
for OID th e"external authentication" is an URI
what is it for OAuth ? a "token" ?
"token"/"provider" pairs ?
Michael de Wit
@mjwwit
Jan 25 2017 13:47
there's the provider, the access token, and a refresh token
Willem van Dreumel
@willemvd
Jan 25 2017 13:47
and all that stuff is done by goth library
Michael de Wit
@mjwwit
Jan 25 2017 13:48
yeah, but we still need to store it somewhere right?
Sandro Santilli
@strk
Jan 25 2017 13:48
yes
and associate that record to a user
userid, provider, token, refresh_token
Willem van Dreumel
@willemvd
Jan 25 2017 13:49
nope, we just need to keep track of the provider used, rest is stored in sessions of the goth lib
we dont need to handle the token ourself
Sandro Santilli
@strk
Jan 25 2017 13:49
NOTE: /admin/users/new let's you pick "github" as the login_source for a new user, that's another symptom of the same hack (considering OAuth a "login_source")
Michael de Wit
@mjwwit
Jan 25 2017 13:49
is it persisted somewhere?
Willem van Dreumel
@willemvd
Jan 25 2017 13:50
yes
session store
Sandro Santilli
@strk
Jan 25 2017 13:51
so it'll be: userid, goth_session
sounds fragile as it tightly binds the model to the implementation
but, if it was a "user_goth" table...
Michael de Wit
@mjwwit
Jan 25 2017 13:52
and OID can be done through goth as well right? Now that your PR is merged @willemvd
Sandro Santilli
@strk
Jan 25 2017 13:53
that's "OpenID Connect"
Willem van Dreumel
@willemvd
Jan 25 2017 13:53
btw I don’t see the need off keeping track of the goth session
Thomas Boerger
@tboerger
Jan 25 2017 13:55
Willem van Dreumel
@willemvd
Jan 25 2017 13:55
that one is totally awesome! :) :) :)
Thomas Boerger
@tboerger
Jan 25 2017 13:56
oh yes
Michael de Wit
@mjwwit
Jan 25 2017 14:03
we're just the best
:joy:
@willemvd we eventually need a way to link a user to 0 or more external login sources
if you know another (better) way of doing that, that's cool too
Sandro Santilli
@strk
Jan 25 2017 14:13
@willemvd: there's a need link a user to an "external login"
Willem van Dreumel
@willemvd
Jan 25 2017 14:48
i will think about a way to get this nicely integrated
Willem van Dreumel
@willemvd
Jan 25 2017 15:04
what if…
we create a new external_login_users table with 3 columns, external_username, user_id and login_source_id
after the "Login with .." button (and user accepts the OAuth2 terms or already has done so):
determine if oauth2 username exists with the given loginSource in the external_login_users or in the user table (as username) with the loginSource
if true: continue with retrieved user from user table
if false: ask if the users wants to create a new account or attach it to some existing user
if create a new account -> use existing code (create a new account with loginSource without password and add to user table)
if attach -> ask to login with existing credentials -> after succesful login, add user to external_login_users table and login with user retrieved from user table
let me know if I have missed some stuff (and if it is clear :P)
matrixbot
@matrixbot
Jan 25 2017 15:58
strk Oid identification is an URI, non a username. How about using an OAuth2 specific table?
strk user_oauth2
strk The rest seems good to me, beside the limit to username/password for confirmation (would prevent to associate a new oauth2 with a user created with another oauth2 or openid)
matrixbot
@matrixbot
Jan 25 2017 16:08
strk Another thing: an admin might want to only delegate logins to a specific oauth prov. In which case the attach-or-register choice should not be given, forcing the "register" choice (autoregister?)
Michael de Wit
@mjwwit
Jan 25 2017 16:09
@willemvd isn't it easier to retrieve a unique value from the OAuth provider (like an email address). If the email-address exists for a Gitea user, the oauth id will be linked to that user, and if it doesn't exist it will create a new user
if you really want to link another oauth id to an existing user, but that id has a different email address, you will need to login to Gitea, go to your user preferences -> external accounts -> add account (and continue from there)
matrixbot
@matrixbot
Jan 25 2017 16:11
strk The code could default to the attach tab if email is found existing. ...
strk With pre-filled fields but still needing a submit. Isn't too annoying unless the provider is really the only auth mechanism.
strk Remember existing instances might not even have a unique email field
strk And I think I saw an "additional emails" table in db?
Kim "BKC" Carlbäcker
@bkcsoft
Jan 25 2017 16:37
they aren't "additional", all emails should be migrated into it, and the Email-field in User-table should be killed
Sandro Santilli
@strk
Jan 25 2017 17:53
agreed
what would the reason be for not getting the output from log.Trace ? did any default recently change ?
logs seem to behave differently
and ROOT_PATH = /tmp/gitea/log
I have LEVEL = Info
Sandro Santilli
@strk
Jan 25 2017 18:00
I confirm, no traces :(
something broke
is Info too high for Trace ?
Kim "BKC" Carlbäcker
@bkcsoft
Jan 25 2017 18:16
to low
or not :/
Sandro Santilli
@strk
Jan 25 2017 18:39
where are the levels shown ?
ie: documented
Kim "BKC" Carlbäcker
@bkcsoft
Jan 25 2017 18:52
modules/log/log.go :rolleyes:
Willem van Dreumel
@willemvd
Jan 25 2017 19:35
It's like in many logging frameworks: trace gives you the most detailed info, debug a little bit less, followed by info , warn , error and the least verbose : fatal
There were some issues with always logging to the console even if you had only configured the file as output. That has been fixed in master recently
I still need to make a issue for xorm logging, that is not configurable or can even be disabled
It will always log and consume disk space AFAIK
@mjwwit @strk will follow up on oauth later or tomorrow ;)
Kim "BKC" Carlbäcker
@bkcsoft
Jan 25 2017 19:45
\o/
Thomas Boerger
@tboerger
Jan 25 2017 19:52
@willemvd I can't remember if it's already merged but there was already an issue or pr for xorm logging
Kim "BKC" Carlbäcker
@bkcsoft
Jan 25 2017 20:04
there's an issue for xorm-logging, and I think there's a PR as well
Willem van Dreumel
@willemvd
Jan 25 2017 20:20
Cool! Lets get that in :)
Henning Henkel
@hhenkel
Jan 25 2017 20:22
Hi all, we've still not migrated from gogs to gitea and I'm not sure if we found a bug or if it is some other error. I'm currently running gitea:1.0 in docker. When I create a new PR with an assignee the assignee is not set on the PR.
Is this a known issue with 1.0, is someone able to simulate that behavior?
Bwko
@Bwko
Jan 25 2017 20:27
@hhenkel This got fixed by #622 and is merged into the latest master :smile:
Henning Henkel
@hhenkel
Jan 25 2017 20:31
@Bwko ah, okay thanks for the info - so I guess if one would want that fixed he would need to go to 1.0 and then to current "latest"?
How stable is HEAD currently? I did not spin up an instance for a couple of weeks.
Bwko
@Bwko
Jan 25 2017 20:36
@hhenkel We'll release 1.1.0 in the next couple of weeks, you could wait for that
Henning Henkel
@hhenkel
Jan 25 2017 20:40
@Bwko Yeah, I saw that the milestone has good progress - but we somehow got the pain to migrate away from gogs. I propably got to sleep over it and test a bit with lastest to see if the main aspects are working for us.
Bwko
@Bwko
Jan 25 2017 20:54
Migrating from Gogs is really easy. Latest master is stable although "bugs happen" :wink:
Henning Henkel
@hhenkel
Jan 25 2017 20:57
Yeah, I did migrate our test-env to gitea, that's why we saw the problem with the assignee. I think I already found an issue with latest, but need to check if it is already reported.
The feature that was introduced with #441 seems to be broken in my env - need to check tomorrow if it is something installation specific (we're migrating from self-compiled to docker) or not.
Bwko
@Bwko
Jan 25 2017 21:05
You mean that the button provided by #441 doesn't work?
At least that's what I've found, and I know how to fix it :smile:
Henning Henkel
@hhenkel
Jan 25 2017 21:13
Yes, exactely, the button seems not work - but not sure what the problem is - I saw some things in the log but had no time to check it in detail.
Bwko
@Bwko
Jan 25 2017 21:18
When you merge 1 branch into another we add a 'merged into xxx' commit.
Then git thinks that there are unmerged changes and therefor refuses to delete the old branch.
I'm working on a PR to fix this
Gregor Santner
@gsantner
Jan 25 2017 21:20
Where do you golang guys do all get this funny gopher icons from? Is there some kind of gopher mascot generator? :D