Basic Auth with Tomcat and the Java Buildpack

[Quintessence]

Good evening all!

I was talking to a Java developer today who is having difficulty with realm based application authentication using the login-config elements in web.xml. He said that he felt he had to change/fork the Java buildpack to make this work as, thus far, he hasn't had success using the buildpack as-is. As far as I can tell, what he's trying to do is very similar to what's being discussed in these three blog posts:

https://johnpfield.wordpress.com/tag/cloud-foundry/

Since I'm not overly familiar with Java I wanted to pose the question here to see if anyone else here is using this type of authentication for your Java apps and if there was a different/simpler way to handle this process?

Thank you!

Quinn

[Daniel Mikusa]

On Tue, Jan 13, 2015 at 10:33 PM, Quintessence <qa...@starkandwayne.com> wrote:

Good evening all!

I was talking to a Java developer today who is having difficulty with realm based application authentication using the login-config elements in web.xml. He said that he felt he had to change/fork the Java buildpack to make this work

That's my understanding as well.  Fork and add config here.

   https://github.com/cloudfoundry/java-buildpack/tree/master/resources/tomcat/conf

 

as, thus far, he hasn't had success using the buildpack as-is. As far as I can tell, what he's trying to do is very similar to what's being discussed in these three blog posts:

https://johnpfield.wordpress.com/tag/cloud-foundry/

Since I'm not overly familiar with Java I wanted to pose the question here to see if anyone else here is using this type of authentication for your Java apps and if there was a different/simpler way to handle this process?

If you use Spring Security, or some other security mechanism that doesn't require changes to the container's configuration, you won't need to fork the Java build pack.

Dan

 

Thank you!

Quinn

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/a5d8ed70-f6f3-4b31-9557-167f1d554bc4%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Quintessence]

Thank you for the response!

I have a follow-up question as well: I haven't done much with Java, I've primarily worked with Go, but I noticed that the Java buildpack requires a lot of forking by comparison. In addition to the below, it's my understanding that switching between Java 7 & 8 or Oracle & OpenJDK require forking. I realize that Go and Java are very different, but I was wondering if someone could help me understand why the Java buildpack is structured this way?

Thank you again :)

[Christopher Frost]

Hi Quinn,

We've designed the buildpack so that making these configuration changes is easy. Ideally the default buildpack will meet the requirements of most uses but if not it should be easy to fork and change it. There are a lot of other users that are happy forking and we currently don't have any thing on the backlog to allow the Java version to be configured without forking but we will consider adding it if more people ask for it.

We always knew that changing the level of Java would result in feedback from the community and we are listening to it. There have been discussions on how to allow users to specify configuration within the application, but we've not been convinced by any example that we've seen yet.  It's not to say that we wouldn't do such a thing, but the value that it added would need to outweigh the complexity that it introduced before we'd start considering the change.

Thanks, Chris.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/966e68c4-0dc0-44a3-9c55-d5ecd6effd7b%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

--
Christopher Frost - GoPivotal UK