Restricting access to fork functioanlity to users with Code access - #2534
Conversation
Signed-off-by: Jonas Franz <info@jonasfranz.software>
Signed-off-by: Jonas Franz <info@jonasfranz.software>
Codecov Report
@@ Coverage Diff @@
## master #2534 +/- ##
=======================================
Coverage 26.96% 26.96%
=======================================
Files 84 84
Lines 16906 16906
=======================================
Hits 4559 4559
Misses 11672 11672
Partials 675 675
Continue to review full report at Codecov.
|
| return func(ctx *Context) { | ||
| var ( | ||
| owner *models.User | ||
| repo *models.Repository |
There was a problem hiding this comment.
Why are these changes to RepoAssignment() necessary? It seems to me that adding the context.LoadRepoUnits() and context.CheckUnit(models.UnitTypeCode) handlers should be sufficient (along with the changes to repo.CanBeForked())
There was a problem hiding this comment.
I think it needs load repo because context.LoadRepoUnits() needs ctx.Reop to context but fork's route only has reopid no repopath.
There was a problem hiding this comment.
Good catch, you're right.
But since we only need to load ctx.Repo, maybe it would be better to add a separate handler for loading :repoid, instead of making RepoAssignment() more complicated by adding a big if/else?
There was a problem hiding this comment.
@ethantkoenig I agree with you to make a new middleware to do that but not change ReopAssignment
Signed-off-by: Jonas Franz <info@jonasfranz.software>
|
@lafriks I think |
|
LGTM |
|
LGTM |
|
LGTM |
|
@JonasFranzDEV please send a back port to v1.2 |
Actual situation: Users how do not have access to
UnitTypeCodecan create a fork of the repository and gain access to the code.This fixes this problem by restiricting access to the fork functionality to users with
UnitTypeCode.