Gitea: 显示公共仓库时出错（404）

创建于 2017-05-24 · 53评论 · 资料来源: go-gitea/gitea

我看到了可能是一个错误的东西（也许是单位）。
如果您按照以下步骤进行操作，则会看到404错误：
1）使用user1创建一个组织（user1在所有者团队中）
2）使用user1创建公共仓库
3）将user2添加到组织中，但不要将其分组
4）使用user2访问组织页面
5）点击存储库
6）404错误

您还可以通过不属于用户的用户访问组织中的公共存储库来拥有404。

似乎404错误是由routers / repo / view.go＃L270触发的。

提交：977dcf96e0d9c5dded47ac6066fad8979a9f74f9

kinbug

资料来源

DblK

👍1

最有用的评论

对于1.3.0，此SQL帮助：

insert into repo_unit ("repo_id", "type", "config") select repository.id, types.*, '{}' from repository left join repo_unit on repository.id=repo_id left join ( select 1 UNION ALL select 2 UNION ALL select 3 UNION ALL select 4 UNION ALL select 5) as types on (1=1) where repo_id is null;

但是，如果有人可以指出这些存储库与其他存储库有何不同，以了解为什么他们的迁移失败会很有用

lafriks 于 2017-12-02

👍4

所有53条评论

因此，不在任何团队中的组织成员应获得什么许可？

lunny 于 2017-05-24

昨天更新服务器后，我也遇到了这个错误。

pgaskin 于 2017-05-24

@lunny ，取决于存储库的类型：

如果它是私有的，那么我认为应该导致403而不是404。（但实际上我认为它们不会显示）
如果是公开的，所有访问权限都像他根本不是组织的一部分

显然，允许组织外部的用户查看公共存储库，即使它不是公共存储库的一部分。

＃404（1797）

DblK 于 2017-05-24

@DblK ，实际上，我们需要一个文档来描述我们喜欢Gitea所做的所有权限设置。

lunny 于 2017-05-25

👍1

你好

就我而言，如果用户只是组织协作者，并且在任何组织团队中，我都看不到任何组织回购。
要获取回购清单，只有在组织所有者团队中设置才可以。

但是在这种情况下，该用户在回购页面上会收到404。在日志中，我显示：

[...routers/repo/view.go:270 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to acces

我可能已经遵循＃1797了（将个人仓库转换为组织仓库）

camlafit 于 2017-05-25

您使用哪个版本？我认为https://github.com/go-gitea/gitea/commit/b0308d86dc124f17d6b67e9d1022a4085c9267e1已修复该问题。

lunny 于 2017-05-25

我刚刚尝试过师父，5分钟前

在1.1.1上还可以

camlafit 于 2017-05-25

因此，任何人都应该访问组织的公共仓库吗？这样，团队的单位应仅适用于组织的私人仓库？

lunny 于 2017-05-25

如果将某个用户设置为任何团队（无论是否是所有者）的协作者或成员，则应向其显示存储库。
如果组织是公开的，则其存储库也应是公开的

camlafit 于 2017-05-25

请确认＃1812解决此问题。

lunny 于 2017-05-26

我认为＃1812解决了此问题，请随时重新打开它。

lunny 于 2017-06-20

你好

抱歉：/
您可以重新打开吗，只是尝试了主人。 404再次出现。

2017/06/20 10:36:54 [I] Log Mode: File(Info)
2017/06/20 10:36:54 [I] XORM Log Mode: File(Info)
2017/06/20 10:36:54 [I] Cache Service Enabled
2017/06/20 10:36:54 [I] Session Service Enabled
2017/06/20 10:36:54 [I] Migration: add user openid table
2017/06/20 10:36:56 [I] Migration: change the key_id and primary_key_id type
2017/06/20 10:36:58 [I] Migration: add show field in user openid table
2017/06/20 10:36:59 [I] Migration: generate and migrate repo and wiki Git hooks
2017/06/20 10:37:00 [I] Migration: change mirror interval from hours to time.Duration
2017/06/20 10:37:01 [I] Migration: add field for repo size
2017/06/20 10:37:01 [I] This migration could take up to minutes, please be patient.
2017/06/20 10:37:21 [I] Migration: add commit status table
2017/06/20 10:37:22 [I] Migration: add primary key to external login user
2017/06/20 10:37:24 [I] Migration: add field for login source synchronization
2017/06/20 10:37:25 [I] Migration: add units for team
2017/06/20 10:37:26 [I] Migration: remove columns from action
2017/06/20 10:38:19 [I] Migration: give all units to owner teams
2017/06/20 10:38:30 [I] Git Version: 2.1.4
2017/06/20 10:38:31 [I] Run Mode: Production
2017/06/20 10:38:31 [I] Listen: http://0.0.0.0:3001

使用的是管理员和所有者组织，它无法访问或更改存储库上的设置。 404显示
我可以提供对该服务器的访问。

camlafit 于 2017-06-20

请提供更多细节。

lunny 于 2017-06-20

你好

在我的日志服务器上，我得到了：

2017/06/20 10:38:31 [I] Listen: http://0.0.0.0:3001
2017/06/20 11:35:12 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:35:22 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:35:37 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:15 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:39 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:43 [...ules/context/repo.go:529 func1()] [E] CheckUnit: You are not allowed to visit this repository unit: 7
[...]

因为我不知道哪种信息有用，所以我可以提供对该服务器的访问。

camlafit 于 2017-06-26

@camlafit你能告诉我这个例子吗？

lunny 于 2017-06-27

你好

在1.1.1上，我有一个具有一些存储库的组织。两个用户分别是管理员（在安装时创建）和一个普通用户，在组织中设置为所有者。

管理员和用户可以检查所有存储库。

如果我更新为母版，则这些帐户始终可以查看组织及其存储库。但是向一个存储库显示，它返回404（到每个帐户）
并且设置存储库也是404。

我认为此存储库与其他存储库之间的区别是创建步骤。通常从管理员帐户创建存储库集直接在组织上。对于此存储库，我认为首先要在用户工作空间上创建，然后再移至组织。

在日志中，我收到此错误：找不到任何单位。

camlafit 于 2017-06-27

较新的更精细的存储库权限设置似乎是一个迁移问题。

pgaskin 于 2017-06-27

@camlafit此回购是私人还是公共的？这个回购在一个组织上吗？

lunny 于 2017-06-28

在一个组织中，它是私人的
其他回购是该组织也是私人的

camlafit 于 2017-06-28

那如果所有人都在一个团队中呢？该团队是否具有对该仓库的读写权限？

lunny 于 2017-06-28

这两个帐户是在团队所有者中设置的，第一个是管理员帐户，另一个是标准帐户。
另一个帐户仅被设置为具有写权限的协作者，而未在所有者团队中设置

在这3种情况下，他们在更新后会收到404

camlafit 于 2017-06-28

@camlafit也许＃1873和＃1968解决了这个问题？您最近测试了哪个版本？

lunny 于 2017-06-28

我在两天前尝试了主版本：5db8cf3bd1505c5c829de2a928d35ea19808b6c2，那么这些提交应该存在。

camlafit 于 2017-06-28

@DblK，请确认您的问题。
@camlafit是否已从Gogs迁移实例？

lunny 于 2017-07-02

这是从头开始安装gitea，使用api导入gitosis。

camlafit 于 2017-07-02

@lunny也许从API单元创建存储库时未正确创建？

lafriks 于 2017-07-02

在此特定情况下，仅使用gitea界面创建了repo和orgo。

camlafit 于 2017-07-02

@lafriks是的。你可能是对的！我会检查的。

lunny 于 2017-07-02

自己打一下，有人找到解决方法吗？

我无法以管理员身份更改存储库的设置，因为该页面只有404s，并且在日志中出现以下错误。

主页：在此存储库中找不到允许您访问的任何单元

olymk2 于 2017-07-12

你好

实际更好的解决方案（以我为例）在1.1.1版本中恢复。我不尝试
与1.1.2

至少允许管理员帐户将设置页面转到任何存储库/组织
应该是有趣的。因此应该可以更正手册

camlafit 于 2017-07-12

我已经测试了很多次，但没有重现该问题。 @camlafit您能否在数据库中显示一些表数据，以便我调查原因。在团队表上有一个名为unit_types 。如果为空，则在存储库页面上将显示404。

lunny 于 2017-07-13

你好

select * from team;
| id | org_id | lower_name | name   | description | authorize | num_repos
| num_members | unit_types          |
|  1 |      2 | owners     | Owners |             |         4 |         7
|           3 | [1,2,3,4,5,6,7,8,9] |

所有行的unit_types列表相同。

camlafit 于 2017-07-13

@camlafit好的。该表是正常的。然后，您可以找到repo_unit表并执行SELECT * FROM repo_unit WHERE repo_id =?吗？应该是404信息库的ID。

lunny 于 2017-07-13

它是空的。

SELECT * FROM repo_unit WHERE repo_id=25;
Empty set (0.00 sec)

camlafit 于 2017-07-17

@camlafit rep_unit表中是否有任何记录？

lafriks 于 2017-07-17

通过回购没有问题，我可以获得数据。

MariaDB [gitea-webelys]> SELECT * FROM repo_unit WHERE repo_id = 16;

+----+---------+------+-------+--------+--------------+
| id | repo_id | type | index | config | created_unix |
+----+---------+------+-------+--------+--------------+
| 69 |      16 |    1 |     1 | {}     |   1490025629 |
| 70 |      16 |    2 |     2 | {}     |   1490025630 |
| 71 |      16 |    3 |     3 | {}     |   1490025630 |
| 72 |      16 |    4 |     4 | {}     |   1490025630 |
| 73 |      16 |    5 |     5 | {}     |   1490025630 |
| 74 |      16 |    6 |     6 | {}     |   1490025630 |
| 75 |      16 |    7 |     7 | {}     |   1490025630 |
+----+---------+------+-------+--------+--------------+
7 rows in set (0.00 sec)

camlafit 于 2017-07-17

看起来是迁移问题，因此必须将单元类型添加到该存储库中

lafriks 于 2017-07-17

怎么样？

但是，如果我理解您的查询，如果我们在team.unit_types中有数据，我们还必须在repo_unit中获得数据吗？无法检查并更新数据库吗？

至少一个通用的SQL解决方法可能是有用的:)

camlafit 于 2017-07-17

@lafriks @camlafit我们可以做两个工作，首先是修复错误，其次是在管理面板上添加一个重置按钮以重置所有回购单位。我将发送公关来做。

lunny 于 2017-07-18

对于unit_types表中缺少的缺少条目的完全相同，是否有一种方法可以重新生成正确的条目？

olymk2 于 2017-07-18

@lunny为什么重置所有回购单位？这将是非常危险的，因为它将丢失有关禁用（Wiki /问题）等的存储库设置

lafriks 于 2017-07-18

你好

重置的GUI看起来很有趣：)在这种情况下，可以通过以下方式访问回购
从admin/repos页回购。如果出现以下情况，将无法访问“回购设置”页面
单位丢失。
在这种情况下，此选项可能很有用，但如果用户或管理员错过了
配置和失去的访问权限。

camlafit 于 2017-07-18

你好

从gogs迁移后，我遇到了同样的问题（表repo_unit为空）。

我为每个repository.id“手动”在表中创建了带有插入项的缺失条目：

insert into repo_unit (`repo_id`, `type`, `index`, `config`) values (73, 1, 1, '{}');

将1,1替换为1,1至7,7 。

这样就足够了吗？

rhaamo 于 2017-07-20

👍1

是的，足够工作了。 @rhaamo

lunny 于 2017-07-20

你好

我已经在服务器上完成了工作，看起来还不错。在28个回购中，有6个没有单位值。

camlafit 于 2017-07-20

@rhaamo欢呼雀跃，基于此，我为以后想要的人提供了更快的版本。

仅在sqlite db上测试


# get repository's ids missing unit types
select repository.id from repository left join repo_unit
on repository.id=repo_id where repo_id is null ;

# create records so you can accually edit and access them again
insert into repo_unit (`repo_id`, `type`, `index`, `config`) 
select repository.id, types.*, '{}' from repository
left join repo_unit on repository.id=repo_id 
left join (
  select 1,1
  UNION ALL select 2,2
  UNION ALL select 3,3
  UNION ALL select 4,4
  UNION ALL select 5,5
  UNION ALL select 6,6
  UNION ALL select 7,7) as types
where repo_id is null;

这使我所有的回购回升到了行动o /

olymk2 于 2017-07-20

👍2 ❤1

更新实例后，我也受到了打击。 https://github.com/go-gitea/gitea/issues/1794#issuecomment -316824479中的查询不适用于MySQL，因此我运行了https://github.com/go-gitea/gitea中建议的查询

silverwind 于 2017-08-11

我认为这是因为您丢失了迁移v16 https://github.com/go-gitea/gitea/blob/master/models/migrations/v16.go#L47。

lunny 于 2017-08-11

我正在将1.1.0+135-gfcc7cda升级到1.1.0+474-gbe29d5f7 ，如果有帮助的话。受影响的存储库肯定以前就可以运行。

silverwind 于 2017-08-11

@lafriks在Discord上向我展示了如何为MySQL修复此问题（再次感谢！）：

insert into repo_unit (`repo_id`, `type`, `index`, `config`) 
select repository.id, types.*, '{}' from repository
left join repo_unit on repository.id=repo_id 
left join (
  select 1 as col1, 1 as col2
  UNION ALL select 2,2
  UNION ALL select 3,3
  UNION ALL select 4,4
  UNION ALL select 5,5) as types on (1=1)
where repo_id is null;

jhasse 于 2017-11-29

👍2

对于1.3.0，此SQL帮助：

insert into repo_unit ("repo_id", "type", "config") select repository.id, types.*, '{}' from repository left join repo_unit on repository.id=repo_id left join ( select 1 UNION ALL select 2 UNION ALL select 3 UNION ALL select 4 UNION ALL select 5) as types on (1=1) where repo_id is null;

但是，如果有人可以指出这些存储库与其他存储库有何不同，以了解为什么他们的迁移失败会很有用

lafriks 于 2017-12-02

👍4

发现如果从Gogs升级到1.1.3到1.2.x，将会发生这种情况。也许将此添加为已知问题并解决文档上的解决方案。

lunny 于 2018-07-06

我现在将关闭它并随时重新打开它。

lunny 于 2018-11-28

此页面是否有帮助？

0 / 5 - 0 等级

Gitea: 显示公共仓库时出错（404）

最有用的评论

所有53条评论

相关问题