Copr URLs

Pierre-Yves Chibon pingou at
Mon Jun 17 08:36:01 UTC 2013

On , Bohuslav Kabrda wrote:
> ----- Original Message -----

> So I would like to propose:
> / > home
> /coprs/ > list all the repos (same as home, atm)
> /coprs/<user>/ > list someone's copr
> /coprs/<user>/<repo>/ > the detail of this copr
> /coprs/<user>/<repo>/{permissions,builds,...}/ > same as now the
> permissions, builds or other page for this repo (the repo file for yum
> could end up here as /coprs/<user>/<repo>/repo/ )

> I've been thinking about this for a long time and this is why I
> decided to not take your proposed way:
> Since Copr doesn't have control over user names (it takes them from
> FAS, currently), we cannot prevent user named e.g. "new" or "edit" to
> register. Since "new" and "edit" are also keywords (/coprs/new/,
> /coprs/edit/) accessed by GET, this would result in an ugly URL
> collision (either user's coprs list would be unaccessible or noone
> would be able to display the "new copr" page).
> Does that make sense or have I missed something?

Hi Slavek,

Indeed, I was missing these two cases. I thought of two approaches:

change the URLs pattern:
- /coprs_new/
- /user_edit/
I'm not big fan of this approach (but it's one)

Incorporate the username in the URL:
- /coprs/<user>/new
- /coprs/<user>/edit <- (this is the edit page of the user prefs
right?, otherwise it should be /coprs/<user>/<repo>/edit)

Since we have the hand on the repos creation we can blacklist "edit"
and "new" as copr name and since a user have to be logged in to access
the new or edit pages we can generate these URLs.

I like this approach more than the previous but, it's a bit of thinking
out loudly here, I'm not sure this is the best solution

Best regards,

More information about the copr-devel mailing list