Date   

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)


Re: special character in db password

Daniel Mikusa
 

On Wed, Sep 30, 2015 at 5:04 PM, Naga Rakesh <nagarakesh4(a)gmail.com> wrote:

It was a user-provided service instance.

Yes, thanks, I was able to figure out that i didn't do a manual URL
encoding and this seems to be working, Thanks,

I have a question now, does this mean the service instance gets connected
to a database based only on the URI? Can we change this approach in our
custom code?
How you interpret service data is entirely up to your application. CF just
provides that information for you via VCAP_SERVICES.

If you use a library to help read service information, which is common for
Java apps, then you'd want to look at how that particular library reads
VCAP_SERVICES. Spring Cloud Connectors does look at the URL, but I don't
believe that's the whole story. I can't recall of the top of my head
though. If you're using that library and curious, you might want to look
closer at the code and see exactly what it's doing.

Dan




On Wed, Sep 30, 2015 at 5:34 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Tue, Sep 29, 2015 at 11:15 PM, Naga Rakesh <nagarakesh4(a)gmail.com>
wrote:

Hello,

I am facing an issue while bounding app to a service instance. The
service instance points to a database which has a '@' (at symbol) in its
password (example : abc(a)def). When I bind this service instance to an
existing app, the app throws up the following error when trying to access
the data.
How did you create this service instance? Is it from a service broker?
or is it a user provided service?



*OUT java.net.UnknownHostException: null: unknown error*
*at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method).*

The sample URI in the env formed was "mysql://username:abc(a)def@
1.1.1.1:3306/dbname", as you can see the password was having a '@'
character in it. I believe how it works is it parses the URI as
*drivername://username:password(a)hostname:port/dbname* and in this case
as the password contains @ it is unable to parse the hostname correctly.
That's because the URL is not valid. Your "@" in the password should be
url encoded (the username and password sections should both be urlencoded,
the "@" is just the only character that would change from being
urlencoded).

If you're passing this URL through a user provided service then you need
to manually urlencode it. If you're using a service broker, then that
sounds like a bug with the broker.

Dan


[abacus] Securing REST endpoints using OAuth bearer access token

Saravanakumar A. Srinivasan
 

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

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: cloud_controller_ng performance degrades slowly over time

Jeffrey Pak
 

We don't see this degradation on any of our environments. We typically deploy at least every two weeks, so it's possible none of our environments are up long enough to exhibit this behavior.

Do you notice this for other endpoints that exercise the CloudController's UAA client (for example: other Organization user types and/or Space users)? Do you see slowdown for any endpoints that do not hit UAA?


Re: special character in db password

Naga Rakesh
 

It was a user-provided service instance.

Yes, thanks, I was able to figure out that i didn't do a manual URL
encoding and this seems to be working, Thanks,

I have a question now, does this mean the service instance gets connected
to a database based only on the URI? Can we change this approach in our
custom code?

On Wed, Sep 30, 2015 at 5:34 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Tue, Sep 29, 2015 at 11:15 PM, Naga Rakesh <nagarakesh4(a)gmail.com>
wrote:

Hello,

I am facing an issue while bounding app to a service instance. The
service instance points to a database which has a '@' (at symbol) in its
password (example : abc(a)def). When I bind this service instance to an
existing app, the app throws up the following error when trying to access
the data.
How did you create this service instance? Is it from a service broker?
or is it a user provided service?



*OUT java.net.UnknownHostException: null: unknown error*
*at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method).*

The sample URI in the env formed was "mysql://username:abc(a)def@
1.1.1.1:3306/dbname", as you can see the password was having a '@'
character in it. I believe how it works is it parses the URI as
*drivername://username:password(a)hostname:port/dbname* and in this case
as the password contains @ it is unable to parse the hostname correctly.
That's because the URL is not valid. Your "@" in the password should be
url encoded (the username and password sections should both be urlencoded,
the "@" is just the only character that would change from being
urlencoded).

If you're passing this URL through a user provided service then you need
to manually urlencode it. If you're using a service broker, then that
sounds like a bug with the broker.

Dan


[abacus] Data structures for temporal usage windows

Jean-Sebastien Delfino
 

Hi Ben,

Following up on our discussion of some of the data structures we can use to
represent our various time windows:
(some background in Github #33 [1] and I've copied the latest Github
comment below as well)

What you're proposing looks pretty good to me. I like your idea of renaming
this array 'windows', and grouping the usage quantity and the related cost,
charge, summary etc together.

This makes clear that the array is about windowing (chopping our stream of
usage into finite temporal windows / buckets), and that 'windows' array is
already contained under a 'usage' object (or 'accumulated_usage',
'aggregated_usage' depending on which usage processing step we're at) so
IMO there's no need to repeat 'usage' again here.

BTW looking at this again triggered another idea about that array, but I
need to think a bit more about it before proposing another minor change on
top of what you have here. Will post again later on that topic.

[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/33

-- Jean-Sebastien

Benjamin Scheng wrote:

In terms of following this design with accumulator and aggregator, it was
changing the quantity to a 7-length array.

When we get to rate, instead of making an equivalent 7-length array for
costs. It'd be better to keep all the values associated with that quantity
in one object(similar to the current and previous quantities in
accumulator). Since it wouldn't make sense to just call it quantity despite
having cost. Here's what the structure would most likely look like in terms
of aggregated_usage:

{ aggregated_usage: [ { metric: 'memory', windows: [{ cost: 0, quantity:
0 }, { cost: 0, quantity: 0 }, { cost: 1, quantity: 1 }, { cost: 24,
quantity: 24 }, { cost: 720, quantity: 720 }, { cost: 8640, quantity: 8640
}, { cost: 86400, quantity: 86400 }] } ] }

'windows' would be holding the new quantity and cost in a 7-length array.
Since charge & summary will also be added to this object during the report,
the name ought to accommodate. At the risk of sounding redundant, would
usage or usage_amount work here better, or is there other terms that would
make more sense?

Thoughts? Suggestions?


Re: [abacus] Adding metering resource

Jean-Sebastien Delfino
 

Hey Piotr,

We're currently registering our sample resource configs in
lib/config/resource/src/index.js [1]. To register yours you can just add
one line like this:

'<your resource_id>': require('<your resource config script>'),

... to that script [1] along with the other sample configs.

Your config doesn't need to be in the resources dir, anywhere on the
node.js require() path should work.

This rudimentary registration mechanism is temporary until we add a
resource config management API to allow service and runtime providers to
register their resource configs externally without having to fiddle with
the Abacus scripts. I believe the plan is to have that API very soon, and
that work is tracked under user story #101019374 [2].

[1]
https://github.com/cloudfoundry-incubator/cf-abacus/blob/master/lib/config/resource/src/index.js#L17
[2] https://www.pivotaltracker.com/story/show/101019374

HTH

-- Jean-Sebastien


On Wed, Sep 30, 2015 at 11:56 AM, Piotr Przybylski <piotrp(a)us.ibm.com>
wrote:

Hi,
I would like to add a new resource, similar to linux-container. What is a
correct way to register that resource ? The resource files are located in
cf-abacus/lib/config/resource/src/resources,
however adding resource file there does not add new resource_id to
resource enumerations (e.g. in cf-abacus/lib/config/resource/src/index.js).

Thank you

Piotr


Re: my app needs to get the number of instances in which its running, (in runtime my app uses this info in my program logic)

CF Runtime
 

The "instances" attribute from the api will give the current number of
instances that should be running. If a user has recently changed this via
the API, the actual number of running instances may be different.

Using the cf cli by shelling out from your app is always a good way to
access the api.

Joseph
CF Release Integration Team

On Wed, Sep 30, 2015 at 7:16 AM, zooba Sir <myfakename90(a)gmail.com> wrote:

will this "instance" attribute gives number of successfully running
instances at the moment or just the maximum no of instances for the app as
configured in manifest.yml

7381 - 7400 of 9422