Date   

Re: Removing FUSE support from CF

Onsi Fakhouri <ofakhouri@...>
 

Hey all,

Based on the feedback we got and the relatively low cost to maintain
privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.

Thoughts?

Onsi

On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com>
wrote:

Hi Onsi,



Ø Thoughts? Concerns?



Well, that’s bad news.



We, and I assume many others as well (like the folks from Stackato who do
it in the public), have used SSHFS + FUSE to implement a persistent file
system for old-fashioned apps/apps that are not Cloud-native. I don’t want
to fight an ideological battle here, it’s just that these apps do still
exist (in majority) and a file system service is an important
service/feature for them.



So if you remove FUSE (which we thought is not going away/was added to
stay), it’s pretty bad for us/many apps.



Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful
for running apps that depend on a persistent FS, like Wordpress. Perhaps
this use case of mounting a remote SSHFS could be supported in some other
way?

Dan








*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF



Hey CF-Dev,



The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!



Diego currently runs applications in *privileged* containers. These
lack the security features outlined above and we are planning on switching
to launch all CF applications in *unprivileged* containers.



Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers becomes
possible we may add it back to the platform.



Thoughts? Concerns?



Thanks!



Onsi

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Logstash and Multiline Log Entry

Steve Wall <steve.wall@...>
 

Now I see what that means. Each line of a multiline log message could be
sent to a different logstash server. Definitely problematic. Especially
with the ephemeral nature of the CF logs there needs to be a viable
solution to persist the logs and syslog seems to be a natural solution. I'm
located in Denver and attend the local CF meetups held in the Pivotal
offices. I believe some LAMB devs attend. I'll be sure to bring it up with
them.
-Steve

On Wed, Jul 29, 2015 at 9:47 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks Steve. Though I'm no logstash expert I assume this won't work if
you have multiple logstash machine's doing filtering like Simon mentioned
right? Same is true for us with splunk if you are forwarding logs to more
than one indexer via the REST api. I'd still like to have a discussion
with Erik about this problem see if he thinks there is anything that can be
done in loggregator to help.

Mike

On Wed, Jul 29, 2015 at 9:00 AM, Steve Wall <
steve.wall(a)primetimesoftware.com> wrote:

Here's a suggested pattern to handle stack traces.


http://stackoverflow.com/questions/31657863/logstash-and-multiline-log-entry-from-cloud-foundry?noredirect=1#comment51279061_31657863


On Mon, Jul 27, 2015 at 11:02 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Yet another request for improved multi line log message handling. Is
there any update from the LAMB team on plans to improve this problem?
There have been several proposed solutions but I'm not aware of anything
actually making it into the LAMB tracker. It would be great if we could
hear from Erik on this issue. Does the LAMB team believe it is not an
issue? Are there plans to improve this situation? Whatever the
perspective lets discuss it as a community and see if there are any options
better than the current. I'd really like to see something turned into a
tracker issue if there are better options.

Mike

[0] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000423.html
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000083.html
[2]
https://groups.google.com/a/cloudfoundry.org/forum/?utm_medium=email&utm_source=footer#!msg/vcap-dev/B1W6_vO0oyo/84X1eAtFsKoJ

On Mon, Jul 27, 2015 at 9:47 AM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

This is a tricky one. Especially if you have more than one logstash
machine doing filtering as they will do filtering independently of each
other as the events come in.

The reason why CF adds a timestamp to each line is because how syslog
works, where each line is its own even.

What we tend to do in my company is to log this kind of stuff via GELF
or with Sentry.

On Mon, Jul 27, 2015 at 5:41 PM, Steve Wall <stevewallone(a)gmail.com>
wrote:

Hello,
We are sending CF logs message to an ELK stack. Multiline logs message
are broken out into several log messages in Logstash. One end per line of
the multiline log message. This is problematic when stack traces dumped to
the log. Each line of the stack trace is translated into a log message.
Trying to view this through Kibana is nearly impossible. Logstash provides
a Grok feature allowing for the manipulation of the log messages. One
common solution is to create a Grok filter that using a timestamp to
indicate when a log entry starts and to combine all lines until the next
timestamp into one log message. The problem is that CF adds a timestamp to
every line. Has anyone come up with a good Grok expression to handle
multiline log message coming out of CF?
Thanks!
Steve



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Filip Hanik
 

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements
https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883


On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Good. But my apologies. Assume:

creation time = 1438184877
access token validity (set by me) = 315360000

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

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

If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time of
creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves exactly
what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Paul Bakare
 

Good. But my apologies. Assume:

creation time = 1438184877
access token validity (set by me) = 315360000

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

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

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time of
creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense as
the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves exactly
what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Notifications on ORG, SPACE and USER modifications

Mike Youngstrom
 

For us the main use case is security auditing to keep a long term record of
who has done anything. In the case of our Security team rather than use CF
events directly they preferred to have events forwarded to Security
Analytics. Today we pull events then forward the details to Security
Analytics via a syslog endpoint.

Mike

[0] http://www.emc.com/security/security-analytics/security-analytics.htm

On Tue, Jul 28, 2015 at 11:26 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi all interested in notifications on modification of resources,

It would be helpful for me in framing the "what" and the "why" of this
feature if you could also describe your specific use cases and pain points
on why you would want notifications on modifications and also which
resources you particularly care about.
Is it for real time updates on a dashboard? For consumption for billing
purposes? For triggering provisioning/deprovisioning of resources?

-Dieu

On Tue, Jul 28, 2015 at 11:05 AM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:

I’m going to need something like this too for the CF Abacus service
metering project, as I’d like to track the lifecycle of orgs, users, etc to
match their history with the usage data reported for them.


Here’s a straw man description of what I had in mind:


- For Abacus, I’d need a Lossless API. Usage metering eventually
translates to billing and money, you don’t want to lose that :)


- An extension or variant of the current CF /v2/events API supporting
users, orgs, app usage etc, as even with a notification API I’ll still need
to do GETs sometimes.


- 304 responses with etags on these GETs (as suggested earlier in the
thread [1]) would be good.


- A Webhook style notification API where I could register interest in a
selection of events with a callback URL, and get these events POSTed back
to me at that URL, similar to what Github and many others do with Webhooks.


- On top of Webhooks, it’d be nice to have a form of streaming (either
down to the client like the Firehose does or in the other direction up to
the Webhook callback URL), but I'm not sure if we’ll need that in the
project right away.


- We’d obviously need some form of security, maybe use my user token to
register for events on entities that I have access to?


- I’m also curious about the group’s thoughts on queueing and
back-pressure when events get generated faster that they can be consumed
for example. There was a mention of some message queuing earlier [2]. That
would make sense to me (although IMO it’d be good if the underlying MQ
didn’t shine through the API). What did you have in mind for this?


I guess there are quite a few things to figure out here! I’ll be happy to
collaborate with the community on these discussions.


Thoughts?


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

[2]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p834.html


- Jean-Sebastien

On Fri, Jul 24, 2015 at 9:59 PM, Matt Cowger <matt(a)cowger.us> wrote:

I think ETags is reasonable thought as well.

On Thu, Jul 23, 2015 at 4:39 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

ETags and a 304 response are specifically intended for that purpose.
I'd recommend that over relying on Last-Modified.


b

On Thu, Jul 23, 2015 at 12:34 AM, Koper, Dies <
diesk(a)fast.au.fujitsu.com> wrote:

Or setting the Last-Modified HTTP response header accordingly, and
allow clients to use HTTP caching mechanisms (Last-Modified, etc.) to get
quick empty responses with the current APIs if no changes have been made?
(Or maybe this is already working so – haven’t checked).



Regards,

Dies Koper



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Matt Cowger
*Sent:* Thursday, July 23, 2015 4:45 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] Notifications on ORG, SPACE and USER
modifications



I've wanted something similar as well.



On a related note, having a CC API 'serial' number (for each object in
CC - apps, spaces, etc) that increments on every change relevant to that
object would be of value for detecting if something has changed.



On Thu, Jul 23, 2015 at 3:27 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

There are a few different approaches to this and different concerns
that are possible.

The requests I've seen have been around wanting to be able to
subscribe to and filter the various events that cc currently generates so
that other behavior could be triggered.

We currently have events, app usage events, and service usage events.

Is it acceptable for the notifications to be lossy? Depends on the
use case but If so, then the firehose may be an acceptable approach.



The CAPI team is currently focusing on other work in the near term,
such as the v3 API and private brokers, but would be happy to collaborate
on a proposal.





On Wed, Jul 22, 2015 at 2:05 PM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com> wrote:

My take:



CC should have callbacks on for each model create, update and delete
methods. Those callbacks will send a message to an MQ, which you can
subscribe to consume those messages.

This can be expanded to pretty much every event we need to track.

What do you think?



JP



2015-07-22 17:30 GMT-03:00 Matthias X Hub <matthias.hub(a)de.ibm.com>:

Hi,

we (=IBM) are also having the need and are currently investigating how
to solve this. We plan to work on a proposal to discuss this further with
the cf community. I'll keep you updated on that.

Regards,
Matthias



From: Mike Youngstrom <youngm(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 22.07.2015 20:57
Subject: Re: [cf-dev] Notifications on ORG, SPACE and USER
modifications
Sent by: cf-dev-bounces(a)lists.cloudfoundry.org
------------------------------




We have the same need. Today we are polling the CC.

It would be nice for us also if we could get CC event notifications
via something like the firehose.

Mike

On Wed, Jul 22, 2015 at 10:23 AM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com> wrote:
I mean, I know you can list those events thru the API, but I want
something that will react on an event instead of having to be constantly
polling for them.

2015-07-22 13:18 GMT-03:00 Juan Pablo Genovese <
juanpgenovese(a)gmail.com>:
Sree,

thanks! Any pointers on how can I hook up to these audit events?

Thank you!

2015-07-22 13:12 GMT-03:00 Sree Tummidi <stummidi(a)pivotal.io>:
I believe there are audit events generated for all these actions which
can be captured and forwarded to an SIEM solution like splunk

Thanks,
Sree

Sent from my iPhone

On Jul 22, 2015, at 8:54 AM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com> wrote:

Guys,

I need to somehow hook up into the Cloud Controller (CC) to capture
ORG, SPACE and USER deletion, insertion and update.

So far, I considered some approaches, such as forking the CC (the
least favorite) and modifying the code with some hooks, tapping into Nginx
to capture the requests, and using triggers in the database to capture each
event and send the necessary info to a service.

What do you think?
Any other idea you might have?

Thanks!

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

Juan Pablo
------------------------------------------------------

http://www.jpgenovese.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev




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

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



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

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


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev





--

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

Juan Pablo
------------------------------------------------------

http://www.jpgenovese.com


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev




_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev





--

-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Jean-Sebastien

Sent from my DynaTAC 8000x

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Logstash and Multiline Log Entry

Mike Youngstrom
 

Thanks Steve. Though I'm no logstash expert I assume this won't work if
you have multiple logstash machine's doing filtering like Simon mentioned
right? Same is true for us with splunk if you are forwarding logs to more
than one indexer via the REST api. I'd still like to have a discussion
with Erik about this problem see if he thinks there is anything that can be
done in loggregator to help.

Mike

On Wed, Jul 29, 2015 at 9:00 AM, Steve Wall <
steve.wall(a)primetimesoftware.com> wrote:

Here's a suggested pattern to handle stack traces.


http://stackoverflow.com/questions/31657863/logstash-and-multiline-log-entry-from-cloud-foundry?noredirect=1#comment51279061_31657863


On Mon, Jul 27, 2015 at 11:02 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Yet another request for improved multi line log message handling. Is
there any update from the LAMB team on plans to improve this problem?
There have been several proposed solutions but I'm not aware of anything
actually making it into the LAMB tracker. It would be great if we could
hear from Erik on this issue. Does the LAMB team believe it is not an
issue? Are there plans to improve this situation? Whatever the
perspective lets discuss it as a community and see if there are any options
better than the current. I'd really like to see something turned into a
tracker issue if there are better options.

Mike

[0] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000423.html
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000083.html
[2]
https://groups.google.com/a/cloudfoundry.org/forum/?utm_medium=email&utm_source=footer#!msg/vcap-dev/B1W6_vO0oyo/84X1eAtFsKoJ

On Mon, Jul 27, 2015 at 9:47 AM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

This is a tricky one. Especially if you have more than one logstash
machine doing filtering as they will do filtering independently of each
other as the events come in.

The reason why CF adds a timestamp to each line is because how syslog
works, where each line is its own even.

What we tend to do in my company is to log this kind of stuff via GELF
or with Sentry.

On Mon, Jul 27, 2015 at 5:41 PM, Steve Wall <stevewallone(a)gmail.com>
wrote:

Hello,
We are sending CF logs message to an ELK stack. Multiline logs message
are broken out into several log messages in Logstash. One end per line of
the multiline log message. This is problematic when stack traces dumped to
the log. Each line of the stack trace is translated into a log message.
Trying to view this through Kibana is nearly impossible. Logstash provides
a Grok feature allowing for the manipulation of the log messages. One
common solution is to create a Grok filter that using a timestamp to
indicate when a log entry starts and to combine all lines until the next
timestamp into one log message. The problem is that CF adds a timestamp to
every line. Has anyone come up with a good Grok expression to handle
multiline log message coming out of CF?
Thanks!
Steve



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Filip Hanik
 

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time of
creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense as
the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves exactly
what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Paul Bakare
 

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)

Except I'm completely getting this all wrong?


Re: Logstash and Multiline Log Entry

Steve Wall <steve.wall@...>
 

On Mon, Jul 27, 2015 at 11:02 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Yet another request for improved multi line log message handling. Is
there any update from the LAMB team on plans to improve this problem?
There have been several proposed solutions but I'm not aware of anything
actually making it into the LAMB tracker. It would be great if we could
hear from Erik on this issue. Does the LAMB team believe it is not an
issue? Are there plans to improve this situation? Whatever the
perspective lets discuss it as a community and see if there are any options
better than the current. I'd really like to see something turned into a
tracker issue if there are better options.

Mike

[0] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000423.html
[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000083.html
[2]
https://groups.google.com/a/cloudfoundry.org/forum/?utm_medium=email&utm_source=footer#!msg/vcap-dev/B1W6_vO0oyo/84X1eAtFsKoJ

On Mon, Jul 27, 2015 at 9:47 AM, Simon Johansson <simon(a)simonjohansson.com
wrote:
This is a tricky one. Especially if you have more than one logstash
machine doing filtering as they will do filtering independently of each
other as the events come in.

The reason why CF adds a timestamp to each line is because how syslog
works, where each line is its own even.

What we tend to do in my company is to log this kind of stuff via GELF or
with Sentry.

On Mon, Jul 27, 2015 at 5:41 PM, Steve Wall <stevewallone(a)gmail.com>
wrote:

Hello,
We are sending CF logs message to an ELK stack. Multiline logs message
are broken out into several log messages in Logstash. One end per line of
the multiline log message. This is problematic when stack traces dumped to
the log. Each line of the stack trace is translated into a log message.
Trying to view this through Kibana is nearly impossible. Logstash provides
a Grok feature allowing for the manipulation of the log messages. One
common solution is to create a Grok filter that using a timestamp to
indicate when a log entry starts and to combine all lines until the next
timestamp into one log message. The problem is that CF adds a timestamp to
every line. Has anyone come up with a good Grok expression to handle
multiline log message coming out of CF?
Thanks!
Steve



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Node.js Apps with small memory limits; Inaccurate Memory Availability in Containers

Mike Dalessio
 

Hi Sai,

Thanks for asking these questions. The buildpacks team, who currently
maintains the nodejs-buildpack, is totally open to improving the node.js
developer experience.

I'd love to hear about anyone's experience managing the total heap size
within the node.js interpreter. If you have played with this, let us know,
and we'd be happy to work with you on how it might work in conjunction with
container memory limits.

Cheers,
-mike

On Wed, Jul 29, 2015 at 10:47 AM, Sai Vennam <svennam92(a)gmail.com> wrote:

Hey All,

I've recently started investigating a memory issue with Node.js apps
running in CloudFoundry environments. FYI, I'm using CFv210. As an
example, if I push a Node.js app with a mem leak with a 512MB memory limit,
the Node.js V8 engine tries to allocate more and more memory until it
passes that memory limit and the application crashes. The behavior I expect
to see is that it will stop trying to allocate more memory when it reaches
the limit, and instead try to GC more aggressively (and then crash at a
later time).

By default, on 64 bit machines, the Node.js v8 engine has a 1GB heap
limit, so I can see why the engine tries to allocate more than is really
available. There should be some way to prevent the Node.js v8 engine from
trying to allocate more than is available. In Java, you can use JVM opts to
set heap limits, maybe something similar?

I did find one thing that might help, --max-old-space-size. But... has any
one done any investigation as to how to set that space size?
"--max-old-space-size" only accounts for the v8 engine's heap, not the
buffers or other processes. For example, should that limit be set to 50% of
the memory_limit? 75%? Maybe that's something the Node.js buildpack should
set as a reasonable default?

There is a separate issue that might be related to this. When you run
'free' or 'top' as a shell command from within the container spun up for my
application, I am seeing "32gb" total. This can't be right... I specified
512 when creating my application! When I run commands like "os.totalmem()"
from within Node.js, I'm also seeing 32gb.

There may be a better solution that doesn't involve setting any params,
but instead just fixing those kernel commands to be accurate.

Thanks,
Sai

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Node.js Apps with small memory limits; Inaccurate Memory Availability in Containers

Sai Vennam <svennam92@...>
 

Hey All,

I've recently started investigating a memory issue with Node.js apps
running in CloudFoundry environments. FYI, I'm using CFv210. As an
example, if I push a Node.js app with a mem leak with a 512MB memory limit,
the Node.js V8 engine tries to allocate more and more memory until it
passes that memory limit and the application crashes. The behavior I expect
to see is that it will stop trying to allocate more memory when it reaches
the limit, and instead try to GC more aggressively (and then crash at a
later time).

By default, on 64 bit machines, the Node.js v8 engine has a 1GB heap limit,
so I can see why the engine tries to allocate more than is really
available. There should be some way to prevent the Node.js v8 engine from
trying to allocate more than is available. In Java, you can use JVM opts to
set heap limits, maybe something similar?

I did find one thing that might help, --max-old-space-size. But... has any
one done any investigation as to how to set that space size?
"--max-old-space-size" only accounts for the v8 engine's heap, not the
buffers or other processes. For example, should that limit be set to 50% of
the memory_limit? 75%? Maybe that's something the Node.js buildpack should
set as a reasonable default?

There is a separate issue that might be related to this. When you run
'free' or 'top' as a shell command from within the container spun up for my
application, I am seeing "32gb" total. This can't be right... I specified
512 when creating my application! When I run commands like "os.totalmem()"
from within Node.js, I'm also seeing 32gb.

There may be a better solution that doesn't involve setting any params, but
instead just fixing those kernel commands to be accurate.

Thanks,
Sai


Re: Invalid password change request

Filip Hanik
 

I don't think the schemas belong there, that may be a copy paste error in
the docs.

The easiest reference for the REST API may be the integration tests

https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/PasswordChangeEndpointIntegrationTests.java#L141-L161


Here are the steps that you can take to reproduce it

Terminal one - Startup the UAA
./gradlew run

Terminal two - Change the password

1. uaac target http://localhost:8080/uaa
2. uaac token owner get cf marissa -s "" -p koala
3. uaac token decode (copy the user_id)
4. uaac -t curl -H"Accept:application/json"
-H"Content-Type:application/json" -XPUT -d '{"password":"newpass",
"oldPassword":"koala"}' /Users/a985b50b-0263-4db8-bbf4-1ac832acc4c3/password

that;s it. the uaac curl adds the -H"Authorization: bearer ..." header. But
you can do it all with curl

On Wed, Jul 29, 2015 at 4:09 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

The uaac is much useful for ops use case. However, my use case leans more
towards the REST API.

Do you an idea why I might be getting those errors. As you can see, the
token has got the right scope.

On Wed, Jul 29, 2015 at 11:38 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

I installed it a while ago and I got some hairy errors. So I just dumped
it.

I'll try it again. Thanks for mentioning.

On Wed, Jul 29, 2015 at 11:37 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Btw why not using uaac client ? Should be much more convenient
https://docs.cloudfoundry.org/adminguide/uaa-user-management.html#changing-passwords


On Wed, Jul 29, 2015 at 6:32 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <
getourneau(a)pivotal.io> wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into
your body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen
below when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get
the following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Filip Hanik
 

Token validity is how long a token is valid for from the time it is
created. The token will store the expiration time, that is the date when
the token expires.
so `"exp":1438209609` is actually the date in seconds when it expires.

To translate exp into a date, you would do

Date expirationDate = new Date(1438209609 * 1000l);

Here is a test case that demonstrates it

https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883

On Wed, Jul 29, 2015 at 4:46 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Filip,

Even when I set the value to 315569260 (this value seems to be lesser than
today though), when I decode the issued token, I get something like this
`"exp":1438209609`.

Is token validity and expiration two different things?



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Paul Bakare
 

Filip,

Even when I set the value to 315569260 (this value seems to be lesser than
today though), when I decode the issued token, I get something like this
`"exp":1438209609`.

Is token validity and expiration two different things?


Re: Invalid password change request

Paul Bakare
 

The uaac is much useful for ops use case. However, my use case leans more
towards the REST API.

Do you an idea why I might be getting those errors. As you can see, the
token has got the right scope.

On Wed, Jul 29, 2015 at 11:38 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

I installed it a while ago and I got some hairy errors. So I just dumped
it.

I'll try it again. Thanks for mentioning.

On Wed, Jul 29, 2015 at 11:37 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Btw why not using uaac client ? Should be much more convenient
https://docs.cloudfoundry.org/adminguide/uaa-user-management.html#changing-passwords


On Wed, Jul 29, 2015 at 6:32 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <
getourneau(a)pivotal.io> wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen
below when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Invalid password change request

Paul Bakare
 

I installed it a while ago and I got some hairy errors. So I just dumped it.

I'll try it again. Thanks for mentioning.

On Wed, Jul 29, 2015 at 11:37 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Btw why not using uaac client ? Should be much more convenient
https://docs.cloudfoundry.org/adminguide/uaa-user-management.html#changing-passwords


On Wed, Jul 29, 2015 at 6:32 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <getourneau(a)pivotal.io
wrote:
I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen
below when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Invalid password change request

Paul Bakare
 

curl -v -H "Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIzMzQ5ZmE1Yy01MDU0LTRiOWYtYmY5My0zZDYyMDFhN2YzMjEiLCJzdWIiOiJ1c2VyYWNjb3VudCIsImF1dGhvcml0aWVzIjpbInNjaW0ucmVhZCIsInNjaW0udXNlcmlkcyIsInVhYS5hZG1pbiIsInVhYS5yZXNvdXJjZSIsImNsaWVudHMucmVhZCIsInNjaW0ud3JpdGUiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIiwic2NpbS5tZSIsImNsaWVudHMuc2VjcmV0IiwicGFzc3dvcmQud3JpdGUiLCJjbGllbnRzLndyaXRlIiwib3BlbmlkIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwib2F1dGguYXBwcm92YWxzIl0sInNjb3BlIjpbInNjaW0ucmVhZCIsInNjaW0udXNlcmlkcyIsInVhYS5hZG1pbiIsInVhYS5yZXNvdXJjZSIsImNsaWVudHMucmVhZCIsInNjaW0ud3JpdGUiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIiwic2NpbS5tZSIsImNsaWVudHMuc2VjcmV0IiwicGFzc3dvcmQud3JpdGUiLCJjbGllbnRzLndyaXRlIiwib3BlbmlkIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwib2F1dGguYXBwcm92YWxzIl0sImNsaWVudF9pZCI6InVzZXJhY2NvdW50IiwiY2lkIjoidXNlcmFjY291bnQiLCJhenAiOiJ1c2VyYWNjb3VudCIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJpYXQiOjE0MzgxNTkxNTMsImV4cCI6MTQzODIwMjM1MywiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsImF1ZCI6WyJ1c2VyYWNjb3VudCIsInNjaW0iLCJ1YWEiLCJjbGllbnRzIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIiwib2F1dGgiXX0.9PZmpcujpHqx2DBn642yzGgV5gVZ-xPCmOsyEQglU08"
-H 'Content-Type: application/json' -d
'{"schemas":["urn:scim:schemas:core:1.0"], "password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password

On Wed, Jul 29, 2015 at 11:32 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen
below when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Invalid password change request

Gwenn Etourneau
 

Btw why not using uaac client ? Should be much more convenient
https://docs.cloudfoundry.org/adminguide/uaa-user-management.html#changing-passwords


On Wed, Jul 29, 2015 at 6:32 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen
below when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Invalid password change request

Gwenn Etourneau
 

Can you show me the body which you are sending the full one ?

On Wed, Jul 29, 2015 at 6:30 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Hi,

I have a valid token with the right scopes and authorities as seen below
when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid
password change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Invalid password change request

Paul Bakare
 

I thought so too. But when I add that I get this:

<html><head><title>Apache Tomcat/7.0.55 - Error report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>The request sent by the client was
syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.55</h3></body></html>

That is, The request sent by the client was syntactically incorrect.

On Wed, Jul 29, 2015 at 11:29 AM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

I think "schemas":["urn:scim:schemas:core:1.0"] is missing into your
body request no ?


On Wed, Jul 29, 2015 at 6:16 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

I have a valid token with the right scopes and authorities as seen below
when decoded:


{"jti":"06ef4e8d-2dc9-4458-9aca-ef89384861c6","sub":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","scope":["password.write","openid","oauth.approvals"],"client_id":"useraccount","cid":"useraccount","azp":"useraccount","grant_type":"password","user_id":"85d99b6e-eaeb-4171-98ba-3e6843f577d7","user_name":"johndoeyAgB4wxoe","email":"
kay1(a)email.com","iat":1438159365,"exp":1438202565,"iss":"
http://localhost:8080/uaa/oauth/token
","aud":["useraccount","password","openid","oauth"]}

However, when I make a request to /Users/[userid]/password, I get the
following error:

"authentication":null,"extraInformation":null,"message":"Invalid password
change request","localizedMessage":"Invalid password change
request","suppressed":[]

The full error log is attached.

To replicate, this is the sample request:

curl -v -H 'Authorization: Bearer
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNmVmNGU4ZC0yZGM5LTQ0NTgtOWFjYS1lZjg5Mzg0ODYxYzYiLCJzdWIiOiI4NWQ5OWI2ZS1lYWViLTQxNzEtOThiYS0zZTY4NDNmNTc3ZDciLCJzY29wZSI6WyJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsIm9hdXRoLmFwcHJvdmFscyJdLCJjbGllbnRfaWQiOiJ1c2VyYWNjb3VudCIsImNpZCI6InVzZXJhY2NvdW50IiwiYXpwIjoidXNlcmFjY291bnQiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX2lkIjoiODVkOTliNmUtZWFlYi00MTcxLTk4YmEtM2U2ODQzZjU3N2Q3IiwidXNlcl9uYW1lIjoiam9obmRvZXlBZ0I0d3hvZSIsImVtYWlsIjoia2F5MUB5b29rb3MuY29tIiwiaWF0IjoxNDM4MTU5MzY1LCJleHAiOjE0MzgyMDI1NjUsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJhdWQiOlsidXNlcmFjY291bnQiLCJwYXNzd29yZCIsIm9wZW5pZCIsIm9hdXRoIl19.dz1ysSNt-TYvVspIqxXizBJp6ZahIv7Q5INwvYmJ430'
-H 'Content-Type: application/json' -d '{"password":"newpass",
"oldPassword":"oldpass03"}' -X PUT
http://localhost:8080/uaa/Users/e39919f6-6f47-45c5-915d-734b9b2f1387/password


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

8421 - 8440 of 9398