HTTP Token Based authentication server?
Is it there any implementation for token based authentication over HTTP? I know there is a OAuth client, but do we have an OAuth server? I'm migrating the authentication of our mobile apps from standard HTTP digest (user/pass base64 encoded) to token based auth, and could find very useful to have something already done to use or to build on top of. Regards! Esteban A. Maringolo
On 28 Jan 2015, at 14:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Is it there any implementation for token based authentication over HTTP?
I know there is a OAuth client, but do we have an OAuth server?
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them.
I'm migrating the authentication of our mobile apps from standard HTTP digest (user/pass base64 encoded) to token based auth, and could find very useful to have something already done to use or to build on top of.
Regards!
Esteban A. Maringolo
2015-01-29 18:57 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 28 Jan 2015, at 14:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Is it there any implementation for token based authentication over HTTP?
I know there is a OAuth client, but do we have an OAuth server?
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them.
I'm migrating the authentication of our mobile apps from standard HTTP digest (user/pass base64 encoded) to token based auth, and could find very useful to have something already done to use or to build on top of.
I could use/test this! By know I'm simply generating a token using to lookup a valid session. Regards! Esteban A. Maringolo
Excerpts from Sven Van Caekenberghe's message of 2015-01-29 22:57:57 +0100:
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them.
you have students looking for projects? there are a bunch of smalltalk related projects on labs.fossasia.org that i am mentoring. not sure if they count as cool though... greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
Hi Martin, this is an interesting site. I saw your lab: "implement a REST API server in Smalltalk" You may want to have a look at: swagger https://github.com/swagger-api/swagger-spec and the additional parts around it. Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js. I think it would be a great project to have support in Zinc, or Moose for that. Maybe this is something students would like to work on. Sebastian On 2015-01-29 5:50 PM, Martin Bähr wrote:
Excerpts from Sven Van Caekenberghe's message of 2015-01-29 22:57:57 +0100:
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them. you have students looking for projects? there are a bunch of smalltalk related projects on labs.fossasia.org that i am mentoring. not sure if they count as cool though...
greetings, martin.
This microframework is quite handy for REST API (and the README of the repo is *really* useful) http://smalltalkhub.com/#!/~zeroflag/Teapot On Fri, Jan 30, 2015 at 3:35 AM, Sebastian Heidbrink <sheidev@yahoo.de> wrote:
Hi Martin,
this is an interesting site.
I saw your lab: "implement a REST API server in Smalltalk"
You may want to have a look at: swagger https://github.com/swagger- api/swagger-spec and the additional parts around it.
Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js.
I think it would be a great project to have support in Zinc, or Moose for that.
Maybe this is something students would like to work on. Sebastian
On 2015-01-29 5:50 PM, Martin Bähr wrote:
Excerpts from Sven Van Caekenberghe's message of 2015-01-29 22:57:57 +0100:
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them.
you have students looking for projects? there are a bunch of smalltalk related projects on labs.fossasia.org that i am mentoring. not sure if they count as cool though...
greetings, martin.
So many options, there is Zinc-REST as well...
On 30 Jan 2015, at 07:29, François Stephany <tulipe.moutarde@gmail.com> wrote:
This microframework is quite handy for REST API (and the README of the repo is *really* useful)
http://smalltalkhub.com/#!/~zeroflag/Teapot
On Fri, Jan 30, 2015 at 3:35 AM, Sebastian Heidbrink <sheidev@yahoo.de> wrote: Hi Martin,
this is an interesting site.
I saw your lab: "implement a REST API server in Smalltalk"
You may want to have a look at: swagger https://github.com/swagger-api/swagger-spec and the additional parts around it.
Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js.
I think it would be a great project to have support in Zinc, or Moose for that.
Maybe this is something students would like to work on. Sebastian
On 2015-01-29 5:50 PM, Martin Bähr wrote: Excerpts from Sven Van Caekenberghe's message of 2015-01-29 22:57:57 +0100: There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them. you have students looking for projects? there are a bunch of smalltalk related projects on labs.fossasia.org that i am mentoring. not sure if they count as cool though...
greetings, martin.
Excerpts from Sven Van Caekenberghe's message of 2015-01-30 07:53:46 +0100:
This microframework is quite handy for REST API (and the README of the repo is *really* useful) http://smalltalkhub.com/#!/~zeroflag/Teapot So many options, there is Zinc-REST as well...
i am aware of both. i want to take a look at Zinc-REST first though. i looked at Teapot briefly. i am not a fan of routing all urls from a central location , i prefer a way where i delegate a namespace say "/people" where a class then is responsible for what happens within that namespace. iaw: if i go to "/people/person/2" then the HandlePeople class would be called with the argument "person/2" or even #(person 2) this allows me to map a REST api to an arbitrary object hierarchy, where the base urls are only defined by the hierarchy which itself is not even aware of REST, and once the object is located i only need to connect the REST interaction to it and have it work the same way regardless of where in the hierarchy that object actually lives. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
Swagger: +100 Le 30 janv. 2015 03:35, "Sebastian Heidbrink" <sheidev@yahoo.de> a écrit :
Hi Martin,
this is an interesting site.
I saw your lab: "implement a REST API server in Smalltalk"
You may want to have a look at: swagger https://github.com/swagger- api/swagger-spec and the additional parts around it.
Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js.
I think it would be a great project to have support in Zinc, or Moose for that.
Maybe this is something students would like to work on. Sebastian
On 2015-01-29 5:50 PM, Martin Bähr wrote:
Excerpts from Sven Van Caekenberghe's message of 2015-01-29 22:57:57 +0100:
There are some students here in Lille that were looking for a cool project, and this is one of the two subjects that I suggested to them.
you have students looking for projects? there are a bunch of smalltalk related projects on labs.fossasia.org that i am mentoring. not sure if they count as cool though...
greetings, martin.
On Jan 30, 2015, at 12:35 AM, Sebastian Heidbrink <sheidev@yahoo.de> wrote:
I saw your lab: "implement a REST API server in Smalltalk"
You may want to have a look at: swagger https://github.com/swagger-api/swagger-spec <https://github.com/swagger-api/swagger-spec> and the additional parts around it.
Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js.
I think it would be a great project to have support in Zinc, or Moose for that.
+1 Beside the technical merits, Swagger has a lot of attention in other communities. Having a Pharo project around it can connect us with the projects they have :) My impression is that it would be strategy wise
Just for your information, I have already implemented a REST service for accessing any Moose model and its objects: http://smalltalkhub.com/#!/~VincentBlondeau/MooseOnWeb. It uses Zinc-REST framework to implement the service. Feel free to contribute or ask more information! Cheers, Vincent BLONDEAU De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de Sebastian Sastre Envoyé : vendredi 30 janvier 2015 14:00 à : Any question about pharo is welcome Objet : Re: [Pharo-users] students looking for projects? On Jan 30, 2015, at 12:35 AM, Sebastian Heidbrink <sheidev@yahoo.de<mailto:sheidev@yahoo.de>> wrote: I saw your lab: "implement a REST API server in Smalltalk" You may want to have a look at: swagger https://github.com/swagger-api/swagger-spec and the additional parts around it. Swagger specs are easy to integrate into many clients via swagger codegen and swagger.js. I think it would be a great project to have support in Zinc, or Moose for that. +1 Beside the technical merits, Swagger has a lot of attention in other communities. Having a Pharo project around it can connect us with the projects they have :) My impression is that it would be strategy wise ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
participants (8)
-
Blondeau Vincent -
Esteban A. Maringolo -
François Stephany -
Martin Bähr -
phil＠highoctane.be -
Sebastian Heidbrink -
Sebastian Sastre -
Sven Van Caekenberghe