Date   

New Cloud Foundry team in Germany and initial working proposal

Simon D Moser
 

Hi cloud foundry community,

it is my pleasure to announce a new cloud foundry team. The main focus of
this new team in the first few months will be on Performance as well as
developing an Event Broadcasting mechanism, which abbreviates to "PEB".
Since PEB is pretty meaningless and the closest real word we found is
"pebble", the team decided to name itself "Team Flintstone", because
pebbles is a famous cartoon personality from the Flintstones series (
https://en.wikipedia.org/wiki/Pebbles_Flintstone ). Flintstone also has a
nice connotation with "Sparks" and "Inceptions", so we really like the
name :-)

I would also like the opportunity to point the community to a google doc
proposal for the event broadcasting work - following a thread that I
attached below. We have been putting together the first of a series of
proposals to implement this capability at:

https://docs.google.com/document/d/1GrIAf8EjW_mz3HUg5Nn4R43d28IkeqH2iYQZHQLfDDQ/edit?pli=1#

Kind regards

Simon Moser

IBM Master Inventor / Bluemix Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Date: 04/09/2015 16:59
Subject: [cf-dev] Re: Notifications for service brokers



To follow up on this, I've been working with Simon Moser on an initial
proposal for this and he is now taking lead on it. Simon just completed a
PM dojo at the end of August.

Dieu

On Tuesday, August 18, 2015, Dieu Cao <dcao(a)pivotal.io> wrote:
I planned to put together a proposal for this a couple of weeks ago as a
strawman to describe use cases, but just have not had the time.
I still hope to tackle this in the next week or so and will post to this
list.

For reference, see this thread [1] where this was previously discussed.

-Dieu
CF CAPI PM

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tt827.html#none

On Tue, Aug 18, 2015 at 5:47 PM, Vineet Banga <vineetbanga1(a)gmail.com>
wrote:
Thanks Juan, I will try to setup a poller for this to achieve similar
functionality. Do you know if there is already proposal for the better
notifications - if yes, could you point me to it? I Would like to see if
it would meet our needs at some point in the future.

On Fri, Aug 14, 2015 at 4:26 PM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com> wrote:
Vineet,

there is some proposals to add better notifications to CF in general and
the CC in particular, but for now you can poll the CC API to get those
events. See http://apidocs.cloudfoundry.org/214/

Thanks!

2015-08-14 18:31 GMT-03:00 Vineet Banga <vineetbanga1(a)gmail.com>:
Is there any notification pub/sub mechanism in cloud foundry when services
are created/updated/deleted. We are exposing few services in CF using
service brokers and we would like some common actions to occur when our
services are created/delete/updated.



--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com


Re: Instance rolling restart feature in CC

Paul Bakare
 

Thank you very much

On Thu, Oct 1, 2015 at 1:31 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Checkout auto pilot plugin here
https://plugins.cloudfoundry.org/ui/
On Oct 1, 2015 20:16, "Kayode Odeyemi" <dreyemi(a)gmail.com> wrote:

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name
and then, after the push is successfull, just switch the route to the app
with the temp name. Not sure there is a built-in feature that allows that,
but you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there
a rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Ronak Banka
 

Checkout auto pilot plugin here
https://plugins.cloudfoundry.org/ui/

On Oct 1, 2015 20:16, "Kayode Odeyemi" <dreyemi(a)gmail.com> wrote:

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there
a rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Paul Bakare
 

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there a
rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Ronak Banka
 

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.

On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there a
rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Simon D Moser
 

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC



Hi

Is it possible to 'cf push' without killing all app instances? Is there a
rolling restart feature in CC

Appreciate your input.


Instance rolling restart feature in CC

Paul Bakare
 

Hi

Is it possible to 'cf push' without killing all app instances? Is there a
rolling restart feature in CC

Appreciate your input.


Implement custom error codes for token validation

Paul Bakare
 

Hi,

During token validation (check_token endpoint), is it possible to get
custom error codes per error message? Error messages such
as {"error":"invalid_token","error_description":"Invalid token (could not
decode) and "Token has expired" maintain singular error code.

I often perform conditional text globbing just to derive the specific token
error like this:

if (response.statusCode != 200 && (answer.error_description != "Token has
expired"))


Re: PHP extension 'gettext' doesn't work?

Hiroaki Ukaji <dt3snow.w@...>
 

Hi.
Thanks a lot for your detailed checks and comments.

Could you include your sample PHP code?
Could you try with the latest build pack? That would rule out any issues
that have been already addressed.
Yes, I'll show my sample code and its results. Please see the following.
So, I take it "hello-world" should be replaced with a localized version?
Yes, I think it should be replaced the other word written in
`message.po` file.
It is true that PHP extension 'gettext' is being installed correctly,
but perhaps it seemed that 'gettext' function doesn't work well.


********** my sample source code **********
URL: https://github.com/hiroakiukaji/php-gettext-test

$ tree
.
├── index.php
└── locale
└── ja_JP.UTF-8
└── LC_MESSAGES
├── messages.mo
└── messages.po


$ vi index.php
<?php

$lang = "ja_JP.UTF-8";
$domain = "messages";

setlocale(LC_ALL, $lang);
bindtextdomain($domain, "./locale/");
textdomain($domain);

// message
echo _("hello world");


$ vi locale/ja_JP.UTF-8/LC_MESSAGES/messages.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL(a)ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-09-29 09:47+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL(a)ADDRESS>\n"
"Language-Team: LANGUAGE <LL(a)li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: index.php:7
msgid "hello world"
msgstr "konnnichiwa sekai"
********************

When we operate the above codes in my local machine, we get following
result.

********** result with my local machine (apache2+php5.5.29 on
Ubuntu14.04)**********
$ curl 127.0.0.1:80
konnnichiwa sekai
********************

In my local environment, the message "hello world" is translated into
japanese sentence, "konnnichiwa sekai".



The results on cloud foundry with 'latest' buildpack is as follows.
(php-buildpack v4.1.4 / cf-release v211 / bosh-lite #552dc68696 / cf-cli
v6.12.0)

********** full output of `cf push` (latest buildpack) **********
$ cf push php-get-test-v4.1.4 -b
https://github.com/cloudfoundry/php-buildpack
Creating app php-get-test-v4.1.4 in org ukaji / space default as ukaji...
OK

Creating route php-get-test-v414.10.244.0.34.xip.io...
OK

Binding php-get-test-v414.10.244.0.34.xip.io to php-get-test-v4.1.4...
OK

Uploading php-get-test-v4.1.4...
Uploading app files from: /home/ukaji/php-gettext-test
Uploading 2.4K, 8 files
Done uploading
OK

Starting app php-get-test-v4.1.4 in org ukaji / space default as ukaji...
-----> Downloaded app package (4.0K)
Cloning into '/tmp/buildpacks/php-buildpack'...
Submodule 'compile-extensions'
(https://github.com/cloudfoundry/compile-extensions) registered for path
'compile-extensions'
Cloning into 'compile-extensions'...
Submodule path 'compile-extensions': checked out
'450ef697e1ea234add05121fbeb5d05b056133c6'
-------> Buildpack version 4.1.4
Installing HTTPD
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/httpd/httpd-2.4.16-linux-x64.tgz]
to [/tmp]
Installing PHP
PHP 5.5.29
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/php/php-5.5.29-linux-x64-1442441030.tgz]
to [/tmp]
Finished: [2015-10-01 06:09:34.369789]
-----> Uploading droplet (41M)

1 of 1 instances running

App started


OK

App php-get-test-v4.1.4 was started using this command `$HOME/.bp/bin/start`

Showing health and status for app php-get-test-v4.1.4 in org ukaji / space
default as ukaji...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: php-get-test-v414.10.244.0.34.xip.io
last uploaded: Thu Oct 1 06:08:49 UTC 2015
stack: cflinuxfs2
buildpack: https://github.com/cloudfoundry/php-buildpack

state since cpu memory disk
details
#0 running 2015-10-01 03:09:48 PM 0.0% 53.6M of 256M 0 of 1G
********************

********** result (latest buildpack) **********
$ curl php-get-test-v414.10.244.0.34.xip.io
hello world
********************

********** `cf logs` when I access a page (latest buildpack) **********
2015-10-01T15:12:19.33+0900 [RTR/0] OUT
php-get-test-v414.10.244.0.34.xip.io - [01/10/2015:06:12:19 +0000] "GET /
HTTP/1.1" 200 0 11 "-" "curl/7.35.0" 10.0.2.15:42716
x_forwarded_for:"192.168.50.1, 10.0.2.15"
vcap_request_id:1ae938d2-0d2c-45b7-4bd5-cfbbccb721e3
response_time:0.007400870 app_id:917e3e17-a77e-4b67-8776-bd0f938132f5
2015-10-01T15:12:19.35+0900 [App/0] OUT 06:12:19 httpd | 192.168.50.1
- - [01/Oct/2015:06:12:19 +0000] "GET / HTTP/1.1" 200 11
vcap_request_id=1ae938d2-0d2c-45b7-4bd5-cfbbccb721e3 peer_addr=10.0.2.15
********************

The results on cloud foundry with 'v211 default' buildpack is as follows.
(php-buildpack v3.2.1 / cf-release v211 / bosh-lite #552dc68696 / cf-cli
v6.12.0)

********** full output of `cf push` (cf v211 default buildpack) **********
$ cf push php-get-test-v3.2.1
Creating app php-get-test-v3.2.1 in org ukaji / space default as ukaji...
OK

Creating route php-get-test-v321.10.244.0.34.xip.io...
OK

Binding php-get-test-v321.10.244.0.34.xip.io to php-get-test-v3.2.1...
OK

Uploading php-get-test-v3.2.1...
Uploading app files from: /home/ukaji/php-gettext-test
Uploading 2.4K, 8 files
Done uploading
OK

Starting app php-get-test-v3.2.1 in org ukaji / space default as ukaji...
-----> Downloaded app package (4.0K)
-------> Buildpack version 3.2.1
Installing HTTPD
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 1534k 100 1534k 0 0 340M 0 --:--:-- --:--:-- --:--:--
340M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 14682 100 14682 0 0 106M 0 --:--:-- --:--:-- --:--:--
106M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_unixd-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 19969 100 19969 0 0 264M 0 --:--:-- --:--:-- --:--:--
264M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_setenvif-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 137k 100 137k 0 0 243M 0 --:--:-- --:--:-- --:--:--
243M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_proxy-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 16787 100 16787 0 0 181M 0 --:--:-- --:--:-- --:--:--
181M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_dir-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 20550 100 20550 0 0 222M 0 --:--:-- --:--:-- --:--:--
222M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_reqtimeout-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 42000 100 42000 0 0 90.0M 0 --:--:-- --:--:-- --:--:--
90.0M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_log_config-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 28927 100 28927 0 0 125M 0 --:--:-- --:--:-- --:--:--
125M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_authz_core-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 25276 100 25276 0 0 68.0M 0 --:--:-- --:--:-- --:--:--
68.0M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_mime-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 31561 100 31561 0 0 136M 0 --:--:-- --:--:-- --:--:--
136M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_proxy_fcgi-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 17805 100 17805 0 0 95.9M 0 --:--:-- --:--:-- --:--:--
95.9M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_remoteip-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 13323 100 13323 0 0 98.4M 0 --:--:-- --:--:-- --:--:--
98.4M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_env-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 72297 100 72297 0 0 325M 0 --:--:-- --:--:-- --:--:--
325M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_mpm_event-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 82878 100 82878 0 0 367M 0 --:--:-- --:--:-- --:--:--
367M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_rewrite-2.4.12.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 16145 100 16145 0 0 112M 0 --:--:-- --:--:-- --:--:--
112M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_authz_host-2.4.12.tar.gz]
to [/tmp]
Installing PHP
PHP 5.5.23
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 5000k 100 5000k 0 0 490M 0 --:--:-- --:--:-- --:--:--
490M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-5.5.23.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 8640k 100 8640k 0 0 549M 0 --:--:-- --:--:-- --:--:--
549M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-fpm-5.5.23.tar.gz]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 18857 100 18857 0 0 224M 0 --:--:-- --:--:-- --:--:--
224M
Downloaded
[https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-gettext-5.5.23.tar.gz]
to [/tmp]
Finished: [2015-10-01 06:00:02.620608]
-----> Uploading droplet (16M)

1 of 1 instances running

App started


OK

App php-get-test-v3.2.1 was started using this command `$HOME/.bp/bin/start`

Showing health and status for app php-get-test-v3.2.1 in org ukaji / space
default as ukaji...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: php-get-test-v321.10.244.0.34.xip.io
last uploaded: Thu Oct 1 05:59:53 UTC 2015
stack: cflinuxfs2
buildpack: PHP

state since cpu memory disk
details
#0 running 2015-10-01 03:00:12 PM 0.0% 26.7M of 256M 0 of 1G
********************

********** result (cf v211 default buildpack) **********
$ curl php-get-test-v321.10.244.0.34.xip.io
hello world
********************

********** `cf logs` when I access a page (cf v211 default buildpack)
**********
2015-10-01T15:05:31.87+0900 [RTR/0] OUT
php-get-test-v321.10.244.0.34.xip.io - [01/10/2015:06:05:31 +0000] "GET /
HTTP/1.1" 200 0 11 "-" "curl/7.35.0" 10.0.2.15:38404
x_forwarded_for:"192.168.50.1, 10.0.2.15"
vcap_request_id:426677e4-e17f-4e0e-5142-75700cd9a33b
response_time:0.003993564 app_id:471f624e-fe67-458e-b788-f131aa271650
2015-10-01T15:05:31.88+0900 [App/0] OUT 06:05:31 httpd | 192.168.50.1
- - [01/Oct/2015:06:05:31 +0000] "GET / HTTP/1.1" 200 11
vcap_request_id=426677e4-e17f-4e0e-5142-75700cd9a33b peer_addr=10.0.2.15
********************

Thanks.

Hiroaki UKAJI



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984p2027.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Saravanakumar A. Srinivasan
 

> Unless I missed something in my reading of section 3-1 of RFC 6350, I don't see where it suggests that we'd need to validate all required parameters of > the request *before* authenticating. The spec describes status code 400 before 401 and 403, but could that be just because 400 < 401 < 403? I'm not > sure that necessarily translates to a sequencing of the checks associated with each status code.

>> invalid_request
>> The request is missing a required parameter,

> AIUI RFC 6350 doesn't mandate any parameter, so I'm not sure why this is even mentioned here. The spec actually discourages the use of (URI query and Form-Encoded) parameters for authorization so I'd advocate for not polluting the code with support for these parameters in the first place. I'm also not reading that sentence as requiring the validation of other application specific parameters (well outside the scope of RFC 6350) to be performed *before* the authentication check.

Agree with you about the comments on *before* and about not polluting the code with support for URI query and Form-Encoded parameters.

>> includes an unsupported parameter or parameter value,

> Makes sense to me, we could reject these OAuth authorization parameters with a 400. 

>> repeats the same parameter,

> Same here, reject one or more, basically any, authorization parameters.

>> uses more than one method for including an access token,

> The above logic would apply here too, we'd only support the Authorization header (and just one).

+1, will update the implementation to return 400 when we get authorization parameters with or without Authorization header.

> or is otherwise malformed

> Other malformations of that Authorization header would translate to a 400 as well.

How would we define a malformed Authorization header? Would a header value not starting with 'bearer ' become a malformed token? 
and how about a header value of 'bearer plaintesttoken'  -  would we consider that as malformed or just an invalid_token? 

How about we just depending on JWT verification to classify these errors using its error message +  401 HTTP response code? is that good enough?

Thanks,
Saravanakumar Srinivasan (Assk),


-----Jean-Sebastien Delfino <jsdelfino@...> wrote: -----
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
From: Jean-Sebastien Delfino <jsdelfino@...>
Date: 09/30/2015 05:16PM
Subject: [cf-dev] Re: [abacus] Securing REST endpoints using OAuth bearer access token

Unless I missed something in my reading of section 3-1 of RFC 6350, I don't see where it suggests that we'd need to validate all required parameters of the request *before* authenticating. The spec describes status code 400 before 401 and 403, but could that be just because 400 < 401 < 403? I'm not sure that necessarily translates to a sequencing of the checks associated with each status code.

Here's my interpretation of the section about the 400 status code -- which could very well be wrong, it's just my interpretation :)

> invalid_request
> The request is missing a required parameter,

AIUI RFC 6350 doesn't mandate any parameter, so I'm not sure why this is even mentioned here. The spec actually discourages the use of (URI query and Form-Encoded) parameters for authorization so I'd advocate for not polluting the code with support for these parameters in the first place. I'm also not reading that sentence as requiring the validation of other application specific parameters (well outside the scope of RFC 6350) to be performed *before* the authentication check.

> includes an unsupported parameter or parameter value,

Makes sense to me, we could reject these OAuth authorization parameters with a 400. 

> repeats the same parameter,

Same here, reject one or more, basically any, authorization parameters.

> uses more than one method for including an access token,

The above logic would apply here too, we'd only support the Authorization header (and just one).

> or is otherwise malformed

Other malformations of that Authorization header would translate to a 400 as well.

Thoughts?

-- Jean-Sebastien

On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <sasrin@...> wrote:
I am working on implementing (see Github commit at [1] for more details) an Express middleware to authenticate incoming requests using OAuth bearer access token. We want to make sure our implementation follows the OAuth 2.0 Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec lists error codes to use when we get an invalid request. In there, the invalid_request error code seems to suggest that we need to validate required request parameters for a particular request before we authenticate the user and return HTTP response code 400 with appropriate error code and error message. It also mentions that we need to return HTTP response code 401, when a request does not contain any authentication information. So it sounds odd for me to validate the request parameters before we validate the authentication of the request. 

Any thoughts? 



Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin@...
Phone: 650 645 8251 (T/L 367-8251)




Re: [abacus] Securing REST endpoints using OAuth bearer access token

Saravanakumar A. Srinivasan
 

> The bearer token generated by UAA is a self validating JWT token which can be to checked for the issuer, signature, expiry, scope etc.

To validate JWT, we are using HMAC Algorithm and a secret, would we be able to use PEM encoded public key for RSA? Looks like this depends on how we have configured the UAA(with symmetric or asymmetric token signing keys). Is my understanding correct?

Thanks,
Saravanakumar Srinivasan (Assk),


-----Sree Tummidi <stummidi@...> wrote: -----
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
From: Sree Tummidi <stummidi@...>
Date: 09/30/2015 04:46PM
Subject: [cf-dev] Re: [abacus] Securing REST endpoints using OAuth bearer access token

Hi,
The access token that you are passing in the header serves as both a proof of authentication & authorization(scopes allowed)
The validation of the request includes checking for the presence of the bearer token and then further checking for the validity of the bearer token.
UAA also exposes an endpoint called check_token but its not a recommended path as this increases the traffic to the server.

The barer token generated by UAA is a self validating JWT token which can be to checked for the issuer, signature, expiry, scope etc.



Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <sasrin@...> wrote:
I am working on implementing (see Github commit at [1] for more details) an Express middleware to authenticate incoming requests using OAuth bearer access token. We want to make sure our implementation follows the OAuth 2.0 Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec lists error codes to use when we get an invalid request. In there, the invalid_request error code seems to suggest that we need to validate required request parameters for a particular request before we authenticate the user and return HTTP response code 400 with appropriate error code and error message. It also mentions that we need to return HTTP response code 401, when a request does not contain any authentication information. So it sounds odd for me to validate the request parameters before we validate the authentication of the request. 

Any thoughts? 



Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin@...
Phone: 650 645 8251 (T/L 367-8251)




Re: Update on Mailman 3 launch

Marco Voelz
 

Pretty much the same here. Haven’t heard back from Eric as well – he tried to reproduce that error some time ago.
@Eric: Any news on that? My Inbox is going crazy on the amount of mails per day :(

Warm regards
Marco

On 30/09/15 17:22, "Marco Nicosia" <mnicosia(a)pivotal.io<mailto:mnicosia(a)pivotal.io>> wrote:

After suddenly realizing I still haven't seen an e-mail to cf-bosh, I have given up.

I've switched all my subscriptions over to Regular, no digests.


--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io<mailto:mnicosia(a)pivotal.io>
c: 650-796-2948


On Thu, Sep 10, 2015 at 8:54 AM, Marco Nicosia <mnicosia(a)pivotal.io<mailto:mnicosia(a)pivotal.io>> wrote:
Hi Marco V,

Thanks for remembering to keep on this.

Now that you mention it, I haven't gotten any cf-bosh digests till I suddenly got two this morning.

But less recent e-mails ("Bosh target password." from Sept 2) have never appeared in my inbox.


--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io<mailto:mnicosia(a)pivotal.io>
c: 650-796-2948<tel:650-796-2948>


On Thu, Sep 10, 2015 at 8:07 AM, Voelz, Marco <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:
Bump & adding Eric and Marco Nicosia directly, just in case. Any updates on this?




On 28/08/15 11:23, "Marco Voelz" <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:

Hi Eric,

Just to confirm, did you leave it enabled in "mime digest" mode for longer than
a day so that there was list traffic to bundle and digest for you? I don't see any
errors in the error log related to MIME digest sends, but see about reproducing this today
and submit a bug.
Yes, I can confirm that I left mime digest on for several days and there were mails which I didn't receive. Note that regular digests aren't working for me, either. Currently the only working setting seems to be single mail delivery, which is not my preferred setting.

Did you manage to reproduce that?

The preference lookup appears to give precedence to the settings on the subscription, then
on the address, then on the user ("global"), and finally on the system
default—it stops at the first defined value it sees. I'll file a bug to have some
better clarification in the UI.
Great, thanks for the bug and the explanation!

Warm regards
Marco


Problems with item delivery, n.000240420

FedEx International Ground <gordon.stafford@...>
 

Dear Customer,

Your parcel has arrived at September 28. Courier was unable to deliver the parcel to you.
Shipment Label is attached to this email.

Yours trully,
Gordon Stafford,
FedEx Delivery Agent.


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Jean-Sebastien Delfino
 

Exactly. We're already using the jsonwebtoken [1] library for the handling
of JWT tokens. The work we've been discussing here is more about
integrating that token validation and the authorization logic in the rest
of our code, and in particular where do we hook the token validation,
before or after our incoming request validation code?

For a more comprehensive authentication solution (which we've not really
started to work on), I'd suggest to look at a library like Passport [2] for
example which works well with the Express framework we're using and comes
with all kind of authentication strategy plugins, incl. support for JWT
with these plugins [3] for example.

[1] https://www.npmjs.com/package/jsonwebtoken
[2] https://www.npmjs.com/package/passport
[3] https://www.npmjs.com/search?q=passport+jwt

- Jean-Sebastien

On Wed, Sep 30, 2015 at 5:30 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

I wouldn't recommend writing this library by hand when there are plenty of
libraries to pick from.

Take a look at "Client libraries" at
http://oauth.net/2/

and there are plenty more.

On Wed, Sep 30, 2015 at 3:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)


Re: [cf-bosh] proposed stemcell network performance tuning

Joshua McKenty <jmckenty@...>
 

Amit - I worry about changes to the former in the context of HTTP 1.0 and 1.1, especially without pipelining. What problem are you trying to solve?

If you’re having trouble initiating new sockets, there are other kernel params we should adjust.

On Sep 29, 2015, at 5:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection to the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can release closed connections faster, making more
# resources available for new connections. Adjust this in the presence of many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections when it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release, diego-release, and perhaps others. Any VM needing to establish a high number of incoming/outgoing tcp connections in a short period of time will be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and will be generally beneficial. The existing defaults made sense for much older networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or feedback about this proposal. If you maintain a bosh release and would like to see how these changes would affect your release, you can create a job which simply does the above in its startup scripts, and colocate that job with all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Filip Hanik
 

I wouldn't recommend writing this library by hand when there are plenty of
libraries to pick from.

Take a look at "Client libraries" at
http://oauth.net/2/

and there are plenty more.

On Wed, Sep 30, 2015 at 3:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)


Re: Update on Mailman 3 launch

Marco Nicosia
 

After suddenly realizing I still haven't seen an e-mail to cf-bosh, I have
given up.

I've switched all my subscriptions over to Regular, no digests.


--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948

On Thu, Sep 10, 2015 at 8:54 AM, Marco Nicosia <mnicosia(a)pivotal.io> wrote:

Hi Marco V,

Thanks for remembering to keep on this.

Now that you mention it, I haven't gotten any cf-bosh digests till I
suddenly got two this morning.

But less recent e-mails ("Bosh target password." from Sept 2) have never
appeared in my inbox.


--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948


On Thu, Sep 10, 2015 at 8:07 AM, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Bump & adding Eric and Marco Nicosia directly, just in case. Any updates
on this?




On 28/08/15 11:23, "Marco Voelz" <marco.voelz(a)sap.com> wrote:

Hi Eric,

Just to confirm, did you leave it enabled in "mime digest" mode for
longer than
a day so that there was list traffic to bundle and digest for you? I
don't see any
errors in the error log related to MIME digest sends, but see about
reproducing this today
and submit a bug.
Yes, I can confirm that I left mime digest on for several days and there
were mails which I didn't receive. Note that regular digests aren't working
for me, either. Currently the only working setting seems to be single mail
delivery, which is not my preferred setting.

Did you manage to reproduce that?

The preference lookup appears to give precedence to the settings on
the subscription, then
on the address, then on the user ("global"), and finally on the system
default—it stops at the first defined value it sees. I'll file a bug
to have some
better clarification in the UI.
Great, thanks for the bug and the explanation!

Warm regards
Marco


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Jean-Sebastien Delfino
 

+1 to that, that's what we're implementing, i.e. not bombarding UAA with
token validation call traffic each time we get usage posted to Abacus :)

Thanks!

-- Jean-Sebastien

Sent from my DynaTAC 8000x

On Wed, Sep 30, 2015 at 4:45 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Hi,
The access token that you are passing in the header serves as both a proof
of authentication & authorization(scopes allowed)
The validation of the request includes checking for the presence of the
bearer token and then further checking for the validity of the bearer token.
UAA also exposes an endpoint called check_token but its not a recommended
path as this increases the traffic to the server.

The barer token generated by UAA is a self validating JWT token which can
be to checked for the issuer, signature, expiry, scope etc.



Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Jean-Sebastien Delfino
 

Unless I missed something in my reading of section 3-1 of RFC 6350, I don't
see where it suggests that we'd need to validate all required parameters of
the request *before* authenticating. The spec describes status code 400
before 401 and 403, but could that be just because 400 < 401 < 403? I'm not
sure that necessarily translates to a sequencing of the checks associated
with each status code.

Here's my interpretation of the section about the 400 status code -- which
could very well be wrong, it's just my interpretation :)

invalid_request
The request is missing a required parameter,
AIUI RFC 6350 doesn't mandate any parameter, so I'm not sure why this is
even mentioned here. The spec actually discourages the use of (URI query
and Form-Encoded) parameters for authorization so I'd advocate for not
polluting the code with support for these parameters in the first place.
I'm also not reading that sentence as requiring the validation of other
application specific parameters (well outside the scope of RFC 6350) to be
performed *before* the authentication check.

includes an unsupported parameter or parameter value,
Makes sense to me, we could reject these OAuth authorization parameters
with a 400.

repeats the same parameter,
Same here, reject one or more, basically any, authorization parameters.

uses more than one method for including an access token,
The above logic would apply here too, we'd only support the Authorization
header (and just one).

or is otherwise malformed
Other malformations of that Authorization header would translate to a 400
as well.

Thoughts?

-- Jean-Sebastien

On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)


Re: [abacus] Securing REST endpoints using OAuth bearer access token

Sree Tummidi
 

Hi,
The access token that you are passing in the header serves as both a proof
of authentication & authorization(scopes allowed)
The validation of the request includes checking for the presence of the
bearer token and then further checking for the validity of the bearer token.
UAA also exposes an endpoint called check_token but its not a recommended
path as this increases the traffic to the server.

The barer token generated by UAA is a self validating JWT token which can
be to checked for the issuer, signature, expiry, scope etc.



Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry


On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)

7361 - 7380 of 9409