search

contao-community-alliance / composer-client

This is the Contao Composer Client
http://de.contaowiki.org/Composer
27 stars 18 forks source link

Request github oauth token #204

Open tristanlins opened 10 years ago

tristanlins commented 10 years ago

If the github api limit is reached, the composer process break because it cannot request a github oauth token from the user. A client tool that request the token from github and write it into the composer.json would solve this problem.

leofeyer commented 10 years ago

But not every ER3 user has a GitHub OAuth token, right?

AFAIK, the rate limit problem does not occur with --prefer-source.

tristanlins commented 10 years ago

AFAIK, the rate limit problem does not occur with --prefer-source.

Thats not correct, especially with prefer source you reach the limit faster, because composer fetch all meta informations (e.g. the existing branches) through the API.

In most cases, this is only for developers and power users ;-)

tristanlins commented 10 years ago

AFAIK, the downloads (prefer dist) are not limited.

leofeyer commented 10 years ago

I think you are wrong: https://github.com/composer/composer/issues/1314#issuecomment-13497719

but for downloads indeed the only ways to fix it right now are using --prefer-source, or providing an oauth API token

It is --prefer-dist which is limited.

tristanlins commented 10 years ago

Mh okay youre right, I use prefer source nearly all the time and run into this problem in every second project ^^ In my 2~3 dist installations I never run into this xD

But what is the conclusion for non-github users? Enforce a github account? Provide a token through a "virtual" github user, that is managed by us?

leofeyer commented 10 years ago

Enforce a github account?

We should not do this.

Provide a token through a "virtual" github user, that is managed by us?

There are ~70,000k Contao installations out there. What are the odds that we reach the rate limit if we use only one single account?

Why is using --prefer-source not an option?

tristanlins commented 10 years ago

There are ~70,000k Contao installations out there. What are the odds that we reach the rate limit if we use only one single account?

AFAIK the rate limit is IP based?!

Why is using --prefer-source not an option?

Because this requires git on the server...

Toflar commented 10 years ago

I still think we should discuss the composer-as-a-service again. I still think this would solve many of our problems. Can we maybe discuss that on the next call for a few minutes or arrange another one specific for ER3 issues?

tristanlins commented 10 years ago

I still think this would solve many of our problems

It will not solve the problem with private and commercial packages.

tristanlins commented 10 years ago

AFAIK the rate limit is IP based?!

Okay, I'm wrong. The rate limit is IP based until you authorize yourself. If you use an oauth token the rate limit is user based. (thx to @discordier)

leofeyer commented 10 years ago

Why is using --prefer-source not an option?

Because this requires git on the server...

You are right, I didn't think about this. Then it seems the only solution is to require people to enter a GitHub OAuth token if they should ever reach the rate limit.

tristanlins commented 10 years ago

Lets talk about this in our composer meeting. This ticket is just a notice for myself ;-)

Toflar commented 10 years ago

@tristanlins: I know we talked about that already a long time ago but @leofeyer and the others probably don't know what we're talking about :) So I took the time to document my ideas. It contains my thoughts regarding the OAuth authorization as well as all the other advantages and disadvantages I could think of :) I hope it can serve as a basis for discussion. https://dl.dropboxusercontent.com/u/3819341/Ideas_ER3_with_Composer.pdf

leofeyer commented 10 years ago

We have discussed this idea a couple of months ago on the NRW Stammtisch, when we were trying to find solutions for the memory limit and script runtime problems.

One of the biggest disadvantages is that we are adding a single point of failure. If the community server is down, no one can use the ER3 anymore. This is also the situation now with the ER2. We did not have much problems with this in the past, though, but we should certainly consider it.

Another disadvantage is that we have to build our own infrastructure instead of "just" setting up a Packagist installation or even using the existing packagist.org service.

On the other hand, if we had a custom infrastructure, it would possibly solve the "commercial extensions" and the "I don't have a GitHub account" problems :)

Toflar commented 10 years ago

One of the biggest disadvantages is that we are adding a single point of failure.

Same as for the whole PHP world today. If packagist.org is down, nothing works ;) Anyway, please remember: We talked about the fact that we need a custom environment (e.g. for our rating feature, licensed extensions, translated extension descriptions etc.) anyway. So if we stick with the composer-on-the-client solution we still have a SPOF, right? :) I'm not trying to say that we should forget about that! Yes, it is a problem, but it's irrelevant for the "can we provide a composer-as-a-service solution" discussion :)

tristanlins commented 10 years ago

I just repeat again. This is NO solution for private repositories. Maybe for commercial repositories that are managed through our ER3. But NOT for commercial repositories that are not managed through our ER3. I repeat myself because I have a private repository in ALL projects. I manage the assets, setting and all the other custom stuff for every web project in a composer project on my gitlab. So I can never use this service... I see this as a recommend way to manage the layout assets and settings for a web project in the future.