Prose should not require access to private repositories #126

Closed
grk opened this Issue Jun 25, 2012 · 25 comments

Comments

Projects
None yet
@grk

grk commented Jun 25, 2012

Since gh pages are public by default, prose shouldn't request access for accessing private repositories (Update your public and private repositories (Commits, Issues, etc).)

@masnick

This comment has been minimized.

Show comment
Hide comment
@masnick

masnick Jun 25, 2012

👍

Ideally I'd like to only be able to give Prose access to a specific repository, either public or private. Lots of people have either:

  1. Private repos on GitHub you really don't want anyone else looking at, or
  2. Public repos on GitHub that you really don't want anyone else to have commit access to (e.g. if you could commit to rails/rails).

masnick commented Jun 25, 2012

👍

Ideally I'd like to only be able to give Prose access to a specific repository, either public or private. Lots of people have either:

  1. Private repos on GitHub you really don't want anyone else looking at, or
  2. Public repos on GitHub that you really don't want anyone else to have commit access to (e.g. if you could commit to rails/rails).
@michael

This comment has been minimized.

Show comment
Hide comment
@michael

michael Jun 25, 2012

Member

Mhh... I have concerns that this violates the principle of least surprise. Prose is a text editor in the first place, so you'd expect to have write access to your repos. Requesting only view acces

In general the authorization works exactly the same as on Github.com. You can only access private repos if your user has access permissions.

So for example.. you can of course view/browse rails/rails.. and even play around with the markup, but you can't save because of the missing permissions.

Member

michael commented Jun 25, 2012

Mhh... I have concerns that this violates the principle of least surprise. Prose is a text editor in the first place, so you'd expect to have write access to your repos. Requesting only view acces

In general the authorization works exactly the same as on Github.com. You can only access private repos if your user has access permissions.

So for example.. you can of course view/browse rails/rails.. and even play around with the markup, but you can't save because of the missing permissions.

@michael

This comment has been minimized.

Show comment
Hide comment
@michael

michael Jun 25, 2012

Member

And github gh-pages are not public in the sense that their source can be edited. Only the generated static content can be accessed using http://username.github.com/reponame.

Closing this ticket for now, reopen if you're unsatisfied. :)

Member

michael commented Jun 25, 2012

And github gh-pages are not public in the sense that their source can be edited. Only the generated static content can be accessed using http://username.github.com/reponame.

Closing this ticket for now, reopen if you're unsatisfied. :)

@michael michael closed this Jun 25, 2012

@masnick

This comment has been minimized.

Show comment
Hide comment
@masnick

masnick Jul 3, 2012

@michael - My issue is giving prose.io access to my entire Github account. I understand that I can't commit to rails/rails but if I was DHH it might be risky for me to allow random third parties access to my account.

I think the principle of having the lowest level of permission necessary to function trumps the principle of least surprise here. This is like apps that use the Dropbox API requiring access to my entire Dropbox account instead of accessing only an app-specific folder.

masnick commented Jul 3, 2012

@michael - My issue is giving prose.io access to my entire Github account. I understand that I can't commit to rails/rails but if I was DHH it might be risky for me to allow random third parties access to my account.

I think the principle of having the lowest level of permission necessary to function trumps the principle of least surprise here. This is like apps that use the Dropbox API requiring access to my entire Dropbox account instead of accessing only an app-specific folder.

@masnick

This comment has been minimized.

Show comment
Hide comment
@masnick

masnick Jul 4, 2012

I blogged about this, and my temporary solution: http://www.maxmasnick.com/2012/07/03/prose/

masnick commented Jul 4, 2012

I blogged about this, and my temporary solution: http://www.maxmasnick.com/2012/07/03/prose/

@michael michael reopened this Jul 4, 2012

@michael

This comment has been minimized.

Show comment
Hide comment
@michael

michael Jul 4, 2012

Member

Thanks. I'll cover your post in the documentation. I need to take some time some time to think through this issue before consider supporting it out of the box.

Member

michael commented Jul 4, 2012

Thanks. I'll cover your post in the documentation. I need to take some time some time to think through this issue before consider supporting it out of the box.

@jrdi

This comment has been minimized.

Show comment
Hide comment

jrdi commented Oct 20, 2012

👍

@dhcole

This comment has been minimized.

Show comment
Hide comment
@dhcole

dhcole Mar 25, 2013

Member

At this time, github's API only supports allowing access to all repos or none -- no granular control access by repos. This would be great, so you could use prose with private or public repose, and only those you specify. People at Github are aware of this limitation and we'll keep an eye for for an update to their API.

Member

dhcole commented Mar 25, 2013

At this time, github's API only supports allowing access to all repos or none -- no granular control access by repos. This would be great, so you could use prose with private or public repose, and only those you specify. People at Github are aware of this limitation and we'll keep an eye for for an update to their API.

@brandonparsons

This comment has been minimized.

Show comment
Hide comment
@brandonparsons

brandonparsons May 26, 2014

This is no longer true, and should be re-opened.

EDIT: My approach actually did not work. Even when you manually downgrade prose's access to public only, it forces private access next time you log in....

This is no longer true, and should be re-opened.

EDIT: My approach actually did not work. Even when you manually downgrade prose's access to public only, it forces private access next time you log in....

@mikemorris mikemorris reopened this May 26, 2014

@PabloReyes

This comment has been minimized.

Show comment
Hide comment
@PabloReyes

PabloReyes Sep 17, 2014

I'm concerned as well about this. I really want to try Prose but I won't if I can't allow access only to my public repositories.

I'm concerned as well about this. I really want to try Prose but I won't if I can't allow access only to my public repositories.

@vance

This comment has been minimized.

Show comment
Hide comment
@vance

vance Dec 5, 2014

Is Prose an extension of the NSA or what (Located in DC)? I guess I'd be more concerned if they were in Virginia. Anyway, blanket access seems prohibitive.

vance commented Dec 5, 2014

Is Prose an extension of the NSA or what (Located in DC)? I guess I'd be more concerned if they were in Virginia. Anyway, blanket access seems prohibitive.

@mikemorris

This comment has been minimized.

Show comment
Hide comment
@mikemorris

mikemorris Dec 5, 2014

Member

This is still on the roadmap as a feature we'd like to add.

@vance The entire codebase is open source, you're more than welcome to fully audit it and run your own hosted instance of Prose if you're concerned.

Member

mikemorris commented Dec 5, 2014

This is still on the roadmap as a feature we'd like to add.

@vance The entire codebase is open source, you're more than welcome to fully audit it and run your own hosted instance of Prose if you're concerned.

@anandthakker

This comment has been minimized.

Show comment
Hide comment
@anandthakker

anandthakker Dec 5, 2014

Contributor

+1 that this is an important issue, in my opinion enough so to warrant even an ugly/hacky workaround that can be done quickly, in advance of a more well-thought-out ux.

@mikemorris I do think @vance and others' concern still applies even if they trust the Prose code itself, since (a) authorizing access to all the repos still means that there's an all-access gh auth token floating around that wouldn't even exist otherwise, and (b) self-hosting isn't trivial and might undermine the very simplicity Prose is offering. Probably you don't need to be convinced of any of this, just stating it for the record in the issue log :)

Contributor

anandthakker commented Dec 5, 2014

+1 that this is an important issue, in my opinion enough so to warrant even an ugly/hacky workaround that can be done quickly, in advance of a more well-thought-out ux.

@mikemorris I do think @vance and others' concern still applies even if they trust the Prose code itself, since (a) authorizing access to all the repos still means that there's an all-access gh auth token floating around that wouldn't even exist otherwise, and (b) self-hosting isn't trivial and might undermine the very simplicity Prose is offering. Probably you don't need to be convinced of any of this, just stating it for the record in the issue log :)

@anandthakker

This comment has been minimized.

Show comment
Hide comment
@anandthakker

anandthakker Dec 5, 2014

Contributor

@vance @PabloReyes Okay, I've been looking at this a little more, and there actually is a relatively simple workaround that's available IMMEDIATELY:

  1. Copy the link address from the "Authorize on Github" button (or the green login button). It should look like: https://github.com/login/oauth/authorize?client_id=...&scope=repo.
  2. Paste that link into the browser, but change repo to public_repo, so that the link now looks like https://github.com/login/oauth/authorize?client_id=...&scope=public_repo.
  3. Navigate there, authorize on Github, and voila: Prose will now have an auth token that only allows access to your public repos.

(Note: when you do this, it seems that your organizations will not show up--a limitation of this workaround, but I hope it might still help some people...)

UPDATE: If you change the link from step 2 above to ...&scope=user,public_repo, you'll get your organizations listed, too.

Contributor

anandthakker commented Dec 5, 2014

@vance @PabloReyes Okay, I've been looking at this a little more, and there actually is a relatively simple workaround that's available IMMEDIATELY:

  1. Copy the link address from the "Authorize on Github" button (or the green login button). It should look like: https://github.com/login/oauth/authorize?client_id=...&scope=repo.
  2. Paste that link into the browser, but change repo to public_repo, so that the link now looks like https://github.com/login/oauth/authorize?client_id=...&scope=public_repo.
  3. Navigate there, authorize on Github, and voila: Prose will now have an auth token that only allows access to your public repos.

(Note: when you do this, it seems that your organizations will not show up--a limitation of this workaround, but I hope it might still help some people...)

UPDATE: If you change the link from step 2 above to ...&scope=user,public_repo, you'll get your organizations listed, too.

@vance

This comment has been minimized.

Show comment
Hide comment
@vance

vance Dec 5, 2014

@mikemorris cool. keep up the good work!

I appreciate all the work you guys are doing with this and the Jekyll community as a whole. I finally got rid of the last bit of server side code for my site just last week!

vance commented Dec 5, 2014

@mikemorris cool. keep up the good work!

I appreciate all the work you guys are doing with this and the Jekyll community as a whole. I finally got rid of the last bit of server side code for my site just last week!

@fulldecent

This comment has been minimized.

Show comment
Hide comment
@fulldecent

fulldecent Feb 3, 2015

@anandthakker Thank you, this fix looks great!

@anandthakker Thank you, this fix looks great!

@brandonparsons

This comment has been minimized.

Show comment
Hide comment
@brandonparsons

brandonparsons Feb 4, 2015

Thank you for the update @anandthakker - I was sad for a minute there as I wanted to use this for an organization and your edit didn't show up in my email tracker :)

Thank you for the update @anandthakker - I was sad for a minute there as I wanted to use this for an organization and your edit didn't show up in my email tracker :)

@PabloReyes

This comment has been minimized.

Show comment
Hide comment
@PabloReyes

PabloReyes Feb 11, 2015

Hey, I just read this now.

That's looks awesome @anandthakker ! Thank you for the support.

I'll give it a try ;)

Hey, I just read this now.

That's looks awesome @anandthakker ! Thank you for the support.

I'll give it a try ;)

@mikemorris

This comment has been minimized.

Show comment
Hide comment
@mikemorris

mikemorris Mar 3, 2015

Member

Closing this as it should be resolved by @dhcole's merged pull request. GitHub also recently rolled out organization-approved applications, allowing organization admins to restrict access to third-party applications to a specific whitelist.

Member

mikemorris commented Mar 3, 2015

Closing this as it should be resolved by @dhcole's merged pull request. GitHub also recently rolled out organization-approved applications, allowing organization admins to restrict access to third-party applications to a specific whitelist.

@mikemorris mikemorris closed this Mar 3, 2015

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 Mar 15, 2015

@mikemorris Do you mind if I ask how #815 resolves this?

I understand that the organization-approved applications feature can be used to mitigate the issue, but I don't think it really resolves it.

In my case, I have access to nearly a dozen Github organizations owned by my employer's clients, most of whom have primarily private repositories. We have recommended using the organization-approved applications to our clients or turned it on for them ourselves where appropriate, but having to ask them to turn on this feature because I want to use a product to manage my personal blog is untenable in my opinion.

Unfortunately, I won't even be able to try out Prose.io unless or until this situation changes. I'm sure there are many other developers who work as consultants that are in the same situation I'm in.

md5 commented Mar 15, 2015

@mikemorris Do you mind if I ask how #815 resolves this?

I understand that the organization-approved applications feature can be used to mitigate the issue, but I don't think it really resolves it.

In my case, I have access to nearly a dozen Github organizations owned by my employer's clients, most of whom have primarily private repositories. We have recommended using the organization-approved applications to our clients or turned it on for them ourselves where appropriate, but having to ask them to turn on this feature because I want to use a product to manage my personal blog is untenable in my opinion.

Unfortunately, I won't even be able to try out Prose.io unless or until this situation changes. I'm sure there are many other developers who work as consultants that are in the same situation I'm in.

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 Mar 15, 2015

I'll also just add that turning on the organization-approved application feature has consequences that need to be dealt with in an orderly fashion:

Setting up third-party application restritions

When an organization admin sets up third-party application restrictions for the first time:

  • Applications that are owned by the organization are automatically given access to the organization's resources.
  • Third-party applications immediately lose access to the organization's resources.
  • SSH keys created before February 2014 immediately lose access to the organization's resources (this includes user and deploy keys).
  • SSH keys created by applications during or after February 2014 immediately lose access to the organization's resources.
  • Hook deliveries from private organization respositories will no longer be sent to unapproved applications.
  • API access to private organization resources is not available for unapproved applications. In addition, there is no create, update, or delete access to public organization resources.
  • Hooks created by users and hooks created before May 2014 will not be affected.
  • Forks of organization-owned repositories are subject to the organization's access restrictions.

md5 commented Mar 15, 2015

I'll also just add that turning on the organization-approved application feature has consequences that need to be dealt with in an orderly fashion:

Setting up third-party application restritions

When an organization admin sets up third-party application restrictions for the first time:

  • Applications that are owned by the organization are automatically given access to the organization's resources.
  • Third-party applications immediately lose access to the organization's resources.
  • SSH keys created before February 2014 immediately lose access to the organization's resources (this includes user and deploy keys).
  • SSH keys created by applications during or after February 2014 immediately lose access to the organization's resources.
  • Hook deliveries from private organization respositories will no longer be sent to unapproved applications.
  • API access to private organization resources is not available for unapproved applications. In addition, there is no create, update, or delete access to public organization resources.
  • Hooks created by users and hooks created before May 2014 will not be affected.
  • Forks of organization-owned repositories are subject to the organization's access restrictions.
@mikemorris

This comment has been minimized.

Show comment
Hide comment
@mikemorris

mikemorris Mar 16, 2015

Member

@md5 #815 is completely unrelated to organization-approved applications. At initial authorization, it should prompt the user with a dropdown to select either public and private repo access (using the repo scope), or just public repo access (using the public_repo scope). https://developer.github.com/v3/oauth/#scopes

Just checked and it looks like although this PR has been merged to master, it hasn't been deployed to gh-pages yet. We really need to fix this structure and make gh-pages the default branch so that a simple merge deploys to production @dereklieu @tristen.

Member

mikemorris commented Mar 16, 2015

@md5 #815 is completely unrelated to organization-approved applications. At initial authorization, it should prompt the user with a dropdown to select either public and private repo access (using the repo scope), or just public repo access (using the public_repo scope). https://developer.github.com/v3/oauth/#scopes

Just checked and it looks like although this PR has been merged to master, it hasn't been deployed to gh-pages yet. We really need to fix this structure and make gh-pages the default branch so that a simple merge deploys to production @dereklieu @tristen.

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 Mar 16, 2015

@mikemorris Thanks for taking the time to clarify! 🤘

md5 commented Mar 16, 2015

@mikemorris Thanks for taking the time to clarify! 🤘

@cjerdonek cjerdonek referenced this issue in sfbrigade/sfbrigade.github.io Mar 27, 2015

Merged

Address issue #37: front page buttons cropped in mobile. #52

@aioue

This comment has been minimized.

Show comment
Hide comment
@aioue

aioue May 12, 2015

I just tried prose and was asked for access to private repos or nothing. Am I missing something?

aioue commented May 12, 2015

I just tried prose and was asked for access to private repos or nothing. Am I missing something?

@ApolloNet

This comment has been minimized.

Show comment
Hide comment
@ApolloNet

ApolloNet Nov 17, 2015

I could not write/save markdown files in an organization repo i own.

What i did to unlock :

  • logout from prose.io
  • copy the URL of the green button at the bottom right
  • changed the parameter &scope to : user,public_repo
  • paste the new URL in my browser
  • changed the permissions granted on organizations i own

I could not write/save markdown files in an organization repo i own.

What i did to unlock :

  • logout from prose.io
  • copy the URL of the green button at the bottom right
  • changed the parameter &scope to : user,public_repo
  • paste the new URL in my browser
  • changed the permissions granted on organizations i own

@dougmet dougmet referenced this issue in ONSdigital/sdg-indicators Apr 24, 2017

Closed

Don't grant prose full permissions #55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment