- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] git feature request

by Dimitris Chloupis

No. It may surprise you but pull requests having nothing to with code review, they are just a formality. To understand pull requests you have to understand character of the person that created git, Linus , the man behind Linux. He is not exactly the most easy going person, and he wanted a VCS that isolated developers rather than bringing together under one roof as SVN is doing. Its not very suprising when you consider the size and complexity of Linux kernel and his not so polite character. Furthermore a pull request offers no practical advantage other than isolation, you can review any commit done directly to the repo and revert back the commits you dont like and open a discussion about it in the issue tracker. Github also offer several other tools, like comments on commits , gist for easy pasting of experimental code etc etc And what makes pull request ever less uselful are branches, git already offers a form of isolation, you can create your own branch in the repo that wont affect the master branch, you can open then a discussion on the issue tracker and you or some other merge the branch to the master branch. Usually master branch is the unstable version anyway , an additional stable branch is usually created for the end users. Also pull requests come with a big disadvantage , fragmentation. Because they lead to the creation of forks . That is not a problem by itself when the fork only contains a handful of commits but a fork can easily deviate without issuing any pull request back to main repo. Its similar to Squeak / Pharo situation, the fork becoming more popular than the main repo. And in the case on Squeak/Pharo is fine because the fork is only one, but a trip to github disneyland will reveal a hell of forks especially for popular repos. This can easily lead to "a war of forks". Pull request essentially offer the advantage of isolation , when you have hundred of developers trying to commit to the project you need some way to keep the ones that you are not familar with out, this is why all very big projects in github use pull requests but also have main contributors. For much smaller projects say 5-10 people its not neccessary, since most likely they will work in branches anyway and because merging to master will be followed after a discussion in the issue tracker. On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote: > > I see a pull request as a way to moderate commits by people that cannot > be > > trusted or that are not regular contributors. > > No. > > The purpose of pull request is to discuss and review the code. > Code reviews should be done whether you are regular contributor or not, > because it's valuable for both the code base, and all people involved. > > Furthermore if you have CI properly configured, then it can execute tests > on the pull request so you know the code is healthy. > > Of course if you work alone or have this is a fun OSS side-project, then > no rules apply. > > Peter > >

July 22, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] JSONWebToken

by Holger Freyther

> On 22 Jul 2016, at 16:17, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi! > Taking the assumption of having 20 service images, every image would need to get back to A in order to check authorization information. The more services images you have the more load it will put on A. In a JWT use case scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization information contained is valid. > 4. S grants C access thank you for the information! I have one rather specific question. How is the token normally transported from C to S? Part of the body/data of a POST/PUT/GET? A custom header inside the HTTP request? kind regards holger

July 22, 2016

Re: [Pharo-dev] [ANN] JSONWebToken

by HernÃ¡n Morales Durand

Thank you for sharing Norbert. Best regards, HernÃ¡n 2016-07-22 5:17 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > Hi, > > thanks to the inquiry of Sven I published an implementation of > JSONWebToken to smalltalkhub. It is available at > > http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken > > For those who don't know JSONWebToken or short JWT pronounced "jot" is a > token format suitable for authentication and authorization. The token > consist of a header, a payload and a signature. The header defines crypto > algorithms, compression and other things needed to read a token on > reception. The payload is called a claim set which is basically a > dictionary with well-known and custom keys. If we think about OAuth or > OpenId the values contained map directly to JWT claims. For OpenID connect > which is an identification mechanism on top of OAuth the usage of JWT is > one of the building blocks. > > What are the advantages in using JWT? > > - it defines a header for encoding the content so it is quite flexible in > the ways compression and encryption of the key is done > - defines a payload which maps arbitrary keys and there is a set of > well-known keys that implementations of OAuth, OpenID can understand > - defines a signature that makes it easy to trust the information > contained or to give the token to someone who is not trusted > - token format is a single line string so it can be used e.g. in HTTP > authentication headers > > A problem JWT can solve: > > In our company we have a lot of little REST servers serving some duties. > To minimize the chaos I want to have a central authentication and > authorization point. If we assume having 20 images running and we look at > typical way how authorization works: > > there is image A (Authentication), image S (Service) und client C. Client > C wants to use the service S > > 1. client C authenticates and retrieves authorization information from A > (or from S which redirects him to A) > 2. client C hands out the authorization information to S > 3. S needs to check at A if the information is valid (client C could have > modified it or generated it) > 4. S grants C access > > Taking the assumption of having 20 service images, every image would need > to get back to A in order to check authorization information. The more > services images you have the more load it will put on A. In a JWT use case > scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization > information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization > information contained is valid. > 4. S grants C access > > FYI, > > Norbert > >

July 22, 2016

Re: [Pharo-dev] [ANN] JSONWebToken

by Denis Kudriashov

2016-07-22 10:17 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > A problem JWT can solve: > > In our company we have a lot of little REST servers serving some duties. > To minimize the chaos I want to have a central authentication and > authorization point. If we assume having 20 images running and we look at > typical way how authorization works: > > there is image A (Authentication), image S (Service) und client C. Client > C wants to use the service S > > 1. client C authenticates and retrieves authorization information from A > (or from S which redirects him to A) > 2. client C hands out the authorization information to S > 3. S needs to check at A if the information is valid (client C could have > modified it or generated it) > 4. S grants C access > > Taking the assumption of having 20 service images, every image would need > to get back to A in order to check authorization information. The more > services images you have the more load it will put on A. In a JWT use case > scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization > information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization > information contained is valid. > 4. S grants C access > Thank's for explanation Norbert. Now I don't need to google about it :)

July 22, 2016

[ANN] JSONWebToken

by Norbert Hartl

Hi, thanks to the inquiry of Sven I published an implementation of JSONWebToken to smalltalkhub. It is available at http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken <http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken> For those who don't know JSONWebToken or short JWT pronounced "jot" is a token format suitable for authentication and authorization. The token consist of a header, a payload and a signature. The header defines crypto algorithms, compression and other things needed to read a token on reception. The payload is called a claim set which is basically a dictionary with well-known and custom keys. If we think about OAuth or OpenId the values contained map directly to JWT claims. For OpenID connect which is an identification mechanism on top of OAuth the usage of JWT is one of the building blocks. What are the advantages in using JWT? - it defines a header for encoding the content so it is quite flexible in the ways compression and encryption of the key is done - defines a payload which maps arbitrary keys and there is a set of well-known keys that implementations of OAuth, OpenID can understand - defines a signature that makes it easy to trust the information contained or to give the token to someone who is not trusted - token format is a single line string so it can be used e.g. in HTTP authentication headers A problem JWT can solve: In our company we have a lot of little REST servers serving some duties. To minimize the chaos I want to have a central authentication and authorization point. If we assume having 20 images running and we look at typical way how authorization works: there is image A (Authentication), image S (Service) und client C. Client C wants to use the service S 1. client C authenticates and retrieves authorization information from A (or from S which redirects him to A) 2. client C hands out the authorization information to S 3. S needs to check at A if the information is valid (client C could have modified it or generated it) 4. S grants C access Taking the assumption of having 20 service images, every image would need to get back to A in order to check authorization information. The more services images you have the more load it will put on A. In a JWT use case scenario the same would look like 1. client C authenticates and receives a JWT containing authorization information. The token is signed by A 2. client C hands out JWT to service S 3. S checks the signature of A and knows that the authorization information contained is valid. 4. S grants C access FYI, Norbert

July 22, 2016

Re: [Pharo-dev] git feature request

by Peter Uhnak

On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote: > I see a pull request as a way to moderate commits by people that cannot be > trusted or that are not regular contributors. No. The purpose of pull request is to discuss and review the code. Code reviews should be done whether you are regular contributor or not, because it's valuable for both the code base, and all people involved. Furthermore if you have CI properly configured, then it can execute tests on the pull request so you know the code is healthy. Of course if you work alone or have this is a fun OSS side-project, then no rules apply. Peter

July 22, 2016

Re: [Pharo-dev] git feature request

by Dimitris Chloupis

Ah yes that's the tool. Generally speaking if you plan to contribute to the repo very frequently being a contributor will allow you to commit directly since in most cases you will be familiar with the repo and know what you doing. I see a pull request as a way to moderate commits by people that cannot be trusted or that are not regular contributors. In case of a pull request it's the workflow that Peter describes but I prefer an addition step, open an issue or link your request to an issue. It make tracking pull requests easier and cleaner. On Fri, 22 Jul 2016 at 10:12, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: > > I'm not sure what the roadmap is for git integration, but just a use case > > that occurs to me while I work "a bit with git" for the first time from > > Pharo. > > > > I install a project via a Baseline from git and makes a small > improvement. > > What is the easiest way to contribute back? I can't push back to the > > personal repo I downloaded from, so the easiest thing would be a single > > menu item to: > > 1. Fork original repository > > 2. Push current in-Image code to a new branch in that fork. > > > > Maybe even... > > 3. Issue a pull request to the original repository. > > This is indeed the idiomatic way to contribute on GitHub. > > 1. fork > 2. install _your fork_ with gitfiletree/remote git repo > 3. make an improvement (you can use master branch, since it's your repo, > but that's a detail) > 4. issue a pull request > > Maybe IceBerg (https://github.com/npasserini/iceberg) could have some > nice interface for this eventually. > > Peter > > > > > > cheers -ben > >

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Dimitris Chloupis

I don't have the problem you have, if I issue the command to redownload the zip it does so and it installs it's code fine. At least the last time I checked with my ChronosManager project to make sure everything works as expected few months ago. Also it does not change the fact that the zip is useless once extracted. On Fri, 22 Jul 2016 at 10:08, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Jul 22, 2016 at 06:54:03AM +0000, Dimitris Chloupis wrote: > > The zip is not needed and it should be deleted after extraction cause it > > serves no role. This create a problem also because if you try to install > > agin the repo it won't redownload the zip , instead it will use the same > > zip. For me this make little sense because in the vast majority of cases > > your intention would be to download the repo version containing the > latest > > commit. There is a command to do this though. Personally I don't like > this > > behavior. > > This is a different problem: > http://forum.world.st/how-to-update-monticello-cypress-repository-downloade… > > Furthermore, deleting the file would have no effect on this, because the > relevant part is what is in the unzipped folder. > > Peter > > > On Fri, 22 Jul 2016 at 06:41, Ben Coman <btc(a)openinworld.com> wrote: > > > > > Just a general observation and first impression of installing a github > > > hosted project. > > > > > > After installing OSSubprocess from the Catalog Browser on Pharo 50760, > > > which uses repository... > > > github://marianopeck/OSSubProcess:v0.2.4/repository > > > > > > ...I see file > > > > "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" > > > sitting next to my .image file. That would seem to dirty up that area > > > when I start to use git more often. I'd expect that file to be placed > in > > > one of the cache folders. > > > > > > cheers -ben > > > > >

July 22, 2016

Re: [Pharo-dev] git feature request

by Peter Uhnak

On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote: > I'm not sure what the roadmap is for git integration, but just a use case > that occurs to me while I work "a bit with git" for the first time from > Pharo. > > I install a project via a Baseline from git and makes a small improvement. > What is the easiest way to contribute back? I can't push back to the > personal repo I downloaded from, so the easiest thing would be a single > menu item to: > 1. Fork original repository > 2. Push current in-Image code to a new branch in that fork. > > Maybe even... > 3. Issue a pull request to the original repository. This is indeed the idiomatic way to contribute on GitHub. 1. fork 2. install _your fork_ with gitfiletree/remote git repo 3. make an improvement (you can use master branch, since it's your repo, but that's a detail) 4. issue a pull request Maybe IceBerg (https://github.com/npasserini/iceberg) could have some nice interface for this eventually. Peter > > cheers -ben

July 22, 2016

Re: [Pharo-dev] github-cache organisation

by Peter Uhnak

On Fri, Jul 22, 2016 at 06:54:03AM +0000, Dimitris Chloupis wrote: > The zip is not needed and it should be deleted after extraction cause it > serves no role. This create a problem also because if you try to install > agin the repo it won't redownload the zip , instead it will use the same > zip. For me this make little sense because in the vast majority of cases > your intention would be to download the repo version containing the latest > commit. There is a command to do this though. Personally I don't like this > behavior. This is a different problem: http://forum.world.st/how-to-update-monticello-cypress-repository-downloade… Furthermore, deleting the file would have no effect on this, because the relevant part is what is in the unzipped folder. Peter > On Fri, 22 Jul 2016 at 06:41, Ben Coman <btc(a)openinworld.com> wrote: > > > Just a general observation and first impression of installing a github > > hosted project. > > > > After installing OSSubprocess from the Catalog Browser on Pharo 50760, > > which uses repository... > > github://marianopeck/OSSubProcess:v0.2.4/repository > > > > ...I see file > > "github--marianopeckOSSubprocessv0241266307023333901887488330764830.zip" > > sitting next to my .image file. That would seem to dirty up that area > > when I start to use git more often. I'd expect that file to be placed in > > one of the cache folders. > > > > cheers -ben > >

July 22, 2016