1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Alex Ley <aley@...>
 

I support this change. 

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Tuesday, June 23, 2020 11:21:12 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Proposal to Rename the Primary Branch on all Cloud Foundry repos
 
I agree.

Dr Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Re: Proposal to Rename the Primary Branch on all Cloud Foundry repos

Dr Nic Williams <drnicwilliams@...>
 

I agree.

Dr Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
Proposal to Rename the Primary Branch on all Cloud Foundry repos

Dieu Cao <dieuc@...>
 

Hey all,
I would like to propose that the cloud foundry projects rename the primary branch on all https://github.com/cloudfoundry and https://github.com/cloudfoundry-incubator repos to “main” as part of Cloud Foundry’s commitment to an inclusive and welcoming community.
I believe some project teams independently have plans to invest in making this change.
Thoughts? Feedback?
-Dieu
Re: Proposal to retire the Perm project in the App Runtime PMC

Guillaume Berche
 

Hi Eric,

Thanks for the clarifications!

Regards,

Guillaume.

Le mar. 23 juin 2020 à 17:08, Eric Malm <emalm@...> a écrit :
Hi, Guillaume,

I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.

I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.

Thanks,
Eric 
From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Re: Proposal to retire the Perm project in the App Runtime PMC

Eric Malm
 

Hi, Guillaume,

I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.

I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.

Thanks,
Eric 

From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
 
Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Martijn de Boer
 

 
I assume the reverse proxy functionality between apps would not work when mutual TLS with X.509 certificates is in place. In this case the certificate (forwarded as header) would be filtered out.
 
Gesendet: Dienstag, 16. Juni 2020 um 09:39 Uhr
Von: "Marco Voelz" <marco.voelz@...>
An: "cf-dev@..." <cf-dev@...>
Betreff: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Great, thanks for the clarification!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 11. June 2020 at 02:46
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Jonathan is correct. 

 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

 

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

 

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

 

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Marco,

 

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

 

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

 

HTH,

Jonathan

 

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

 
Updated Password policy will be changed to configurations added in uaa.yml file after restarting uaa tomcat. #cf #uaa

shilpa kulkarni
 

Hi All,

I have used update identity provider api(https://docs.cloudfoundry.org/api/uaa/version/74.21.0/index.html#update) to update the password policy.
It worked for me. But if I restart my uaa tomcat then the password policy will be changed to configurations added in uaa.yml. Why the settings will change?Can anyone please provide solution for this?

Thanks & Regards
Shilpa Kulkarni
Re: Customize the Email content of password reset request #cf #uaa

shilpa kulkarni
 

I got to know to change the email content of password reset request. In the uaa tomcat in the templates\mail\reset_password.html file I have customized the content. But I want to pass username in the email content but not getting the username. Can anyone please help me in resolving the issue?
Re: BOSH PMC: Quarks Project Lead call for Nominations

Vlad Iovanov
 

Hi, everyone,

 

SUSE is nominating Mario Manno for the Quarks Project Lead in the BOSH PMC.

 

Mario works as an open-source developer in the platform department at SUSE.

He joined the Cloud Foundry Foundation as a committer in 2017.

He now works on project Quarks to create Kubernetes controllers for Cloud Foundry.

 

Thanks,

Vlad Iovanov

 

From: Marco Voelz via lists.cloudfoundry.org
Sent: Thursday, June 18, 2020 9:52 AM
To: cf-bosh@...; cf-dev@...
Subject: [cf-bosh] BOSH PMC: Quarks Project Lead call for Nominations

 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead

 
Re: [CAUTION] [cf-dev] BOSH PMC: Quarks Project Lead call for Nominations

Marco Voelz
 

Hi everyone,

 

SUSE is nominating Mario Manno for the Quarks Project Lead in the BOSH PMC.

Mario works as an open-source developer in the platform department at SUSE.

He joined the Cloudfoundry Foundation as a committer in 2017.

He now works on project Quarks to create Kubernetes controllers for Cloudfoundry.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 18. June 2020 at 08:54
To: "cf-bosh@..." <cf-bosh@...>, "cf-dev@..." <cf-dev@...>
Subject: [CAUTION] [cf-dev] BOSH PMC: Quarks Project Lead call for Nominations

 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead
BOSH PMC: Quarks Project Lead call for Nominations

Marco Voelz
 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead
Re: Proposal to retire the Perm project in the App Runtime PMC

Guillaume Berche
 

Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Update on the GA of cf CLI V7

Josh Collins <collinsjo@...>
 

Good Afternoon, Good Morning, and Good Evening,


We'd like to share a quick update regarding the GA of the v7 CLI. We're confident in the v7 GA and although the original target date hasn’t changed, we've made a few adjustments to how we’ll approach GA that you should be aware of.


TL;DR

  • We expect version 7.0.0 to release on or before June 22nd

  • The 7.0.0 release should have no impact to existing systems/workflows that rely on the v6 cf CLI

  • Thank you!


For those interested in more detail...

The following milestones are no longer considered pre-requisites for the GA of the v7 CLI (rationales for each is provided further below):


  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI

  2. Getting the v7 CLI running in all of Release Integration's CF-Deployment CI pipelines


Rationales for the removal of  the following milestones:

  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI:
    The v7 CLI depends on the latest CAPI release (v1.95.0), which the vast majority of foundations running in the wild will not have deployed yet.

    We’ve decided to publish the v7 GA to the various package managers we support in the same manner as we have been publishing the v7 betas.  Folks already consuming the v7 beta via a package manager should be updated to 7.0.0 the next time they update. Please note that the binary name of the cf CLI 7.0.0 will be `cf`, as opposed to the beta binary name `cf7`.

    This is intended to minimize disruption to the community and afford the CLI team the time we need to work through the discovered complexities of package management.

    As a result, staying on the major version of the CLI that you are currently consuming from package managers will not require special intervention (with the exception of those who are consuming the beta v7).

    For those who must do so, our Downloads section of the CLI README will be updated with instructions on how to switch back and forth between the v7 and v6 CLIs.

  2. Getting the v7 CLI running in all of the Release Integration team’s (RelInt’s) CF-Deployment CI pipelines:
    The purpose of RelInt's pipelines is to validate the stability of a particular combination of the component releases specified in the CF-Deployment manifest. In the context of RelInt's pipelines, the CLI is used as a vehicle to exercise the platform, and when their pipelines run green, a release of CF-Deployment can be published.

    While this milestone provides valuable information, it's not primarily a validation of the CLI itself. The pipelines that the CLI team manage test the CLI exhaustively.  When our pipelines run green, we can confidently release a version of CLI, including the GA of v7.

    That said, we've worked with the Release Integration team to get a copy of one of their pipelines running with the v7 CLI release candidate against a branch of cf-acceptance-tests with modifications necessary to run it.

    This helps us build confidence that the coming migration of all of the Release Integration team's pipelines will be relatively smooth.


We appreciate any efforts you take to share this information with others in the community and look forward to the GA of the cf CLI!


For more information and/or questions about the v7 CLI, please visit Cloud Foundry docs, message us on slack, or visit our github.


Thanks so very much,


The CLI Team
Re: Route integrity on Windows

Matthew Horan <hmatthew@...>
 

Hi Aaron,

As you've discovered, the experimental route integrity ops file exists and is a stopgap until Envoy Windows porting work is complete. This experimental ops file uses nginx in place of Envoy, and should be suitable for most usage. It is still considered experimental because we have not received much feedback on it, however we have been using it internally at VMware with no issues for some time now.

VMware and Microsoft are actively working on porting Envoy to Windows, as you noted. This work is ongoing, and no delivery date is available at this time. We are currently working to address performance issues due to the eventing model on Windows specifically, with Microsoft is leading those efforts.

I would recommend trying out the experimental ops file to see if it suits your needs. Please feel free to engage with us if you discover issues, as we would love the feedback and look to improve the experience.

Best,
Matt

From: cf-dev@... <cf-dev@...> on behalf of Aaron Huber <aaron.m.huber@...>
Sent: Friday, June 12, 2020 5:32 PM
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] Route integrity on Windows
 

We have been waiting for some time for a solution for route integrity support on Windows and I wanted to check on the status and compare notes on what others are doing.

 

We are still using the Windows 2012 R2 stack because we require IPSec encryption of the HTTP traffic between the router and the instance.  Overall CF has made great progress on removing all non-encrypted traffic across the platform and the last two places where encryption is missing are nats which is finally underway, and route integrity on Windows.  Once we close those two gaps we’ll finally be able to stop using IPSec on the platform, but until then, since Windows 2019 still doesn’t support IPSec along with NAT in containers, we are stuck with the older stack.

 

There are a few options that we know of:

 

  • Use the experimental route integrity ops file using Nginx instead of envoy – is anyone using this successfully in production?
  • Wait for Envoy support on Windows – this has been in progress for a while and Microsoft still seems to be actively working on it, but once it becomes available will support for it be added to Cloud Foundry?
  • Wait for Kubernetes support to be fully production ready – hopefully the new platform will be fully encrypted from the beginning

 

What are other platform operators that offer Windows support doing for now?

 

 

Aaron Huber

Intel Corporation
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Marco Voelz
 

Great, thanks for the clarification!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 11. June 2020 at 02:46
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Jonathan is correct. 

 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

 

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

 

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

 

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Marco,

 

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

 

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

 

HTH,

Jonathan

 

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Customize the Email content of password reset request #cf #uaa

Dr Nic Williams <drnicwilliams@...>
 

Perhaps try finding the UAA core team on the CF Slack in the #uaa room and they might be able to help you.

Nic

On Mon, 15 Jun 2020 at 5:18 am, shilpa kulkarni <shilpakulkarni91@...> wrote:
Hi,

I am using UAA war file in tomcat. I want to customize the email content of password reset request. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa

--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
customize the validation message of mismatching password and confirm password in reset password page #uaa #cf

shilpa kulkarni
 

Hi,

I am using UAA war file in tomcat. I want to customize the validation message of mismatching password and confirm password (in reset password page). I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Customize the Email content of password reset request #cf #uaa

shilpa kulkarni
 

Hi,

I am using UAA war file in tomcat. I want to customize the email content of password reset request. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Re: Reset password : if the unregistered email address entered then also giving success message. #cf #uaa

Jonathan Matthews <contact+cfdev@...>
 

Hey Shilpa,

I wouldn’t be surprised to find this is intentional. 

If this didn’t happen, then it would be possible for an attacker to try submitting many addresses, and then receive confirmation of which of them were related to accounts on the service/system.

I also wouldn’t be surprised to find that the service had an option to disable this behaviour in trusted environments, but I’ve no insight into that - I’m just mentioning that’s it’s /possible/ :-)

HTH,
J

On Sun, 14 Jun 2020 at 16:59, shilpa kulkarni <shilpakulkarni91@...> wrote:
Hi,
 
If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?
 
Thanks & Regards
Shilpa

--
Jonathan Matthews
London, UK
https://jpluscplusm.com
Reset password : if the unregistered email address entered then also giving success message. #cf #uaa

shilpa kulkarni
 

Hi,
 
If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?
 
Thanks & Regards
Shilpa
381 - 400 of 9431