search

shawnmckinney / apache-fortress-demo

Sample web app to demo end-to-end security w/ JavaEE, Spring Security and RBAC fine-grained authorization. All connections use SSL.
Apache License 2.0
19 stars 11 forks source link

Parameters in the instructions for step IX not in the parameter file #4

Closed ussmith closed 7 years ago

ussmith commented 9 years ago

For clarity it might make sense to add

These are the connection parameters used for LDAP service account and used by 'admin' pooled connections:

root.dn=uid=admin,ou=system port=10389

and

This param tells fortress what type of ldap server in use:

ldap.server.type=apacheds

To the src/main/resources/fortress.properties, even if they're commented out. I'm not going to change this one because I may be misunderstanding the intent.

ussmith commented 9 years ago

And I have no idea why it did that to the font. I promise, I'm not shouting.

shawnmckinney commented 9 years ago

I have shuffled this doc around a bit. The instructions for installing apache directory, studio, tomcat, core, realm, web and rest are generated here: https://git-wip-us.apache.org/repos/asf?p=directory-fortress-core.git;a=blob;f=README-TEN-MINUTE-GUIDE.txt;h=76f8e4a106561652418b03d2b7ca19a4cafc9b8e;hb=1318ad7c26cded619d1d43554109113e1b8c9e6f

The apache demo will be changed to include instructions for creating keys, installing mysql, and configuring the above apps for TLS.

One of the changes is to property setup as I agree it is confusing. After the fortress.properties file has been created and verified in the core setup, it will be copied to each of the dependent apps during their setup.

Most of the screen shots and suggestions you have made recently has been added to the new docs. The fortress ten minute guide is done. I'm working on the new demo instructions now. Getting hung up on TLS config for directory and fortress...

On Fri, Feb 13, 2015 at 3:25 PM, Shawn Eion Smith notifications@github.com wrote:

For clarity it might make sense to add These are the connection parameters used for LDAP service account and used by 'admin' pooled connections:

root.dn=uid=admin,ou=system port=10389

and This param tells fortress what type of ldap server in use:

ldap.server.type=apacheds

To the src/main/resources/fortress.properties, even if they're commented out. I'm not going to change this one because I may be misunderstanding the intent.

— Reply to this email directly or view it on GitHub https://github.com/shawnmckinney/apache-fortress-demo/issues/4.

shawnmckinney commented 9 years ago

LOL!

On Fri, Feb 13, 2015 at 3:27 PM, Shawn Eion Smith notifications@github.com wrote:

And I have no idea why it did that to the font. I promise, I'm not shouting.

— Reply to this email directly or view it on GitHub https://github.com/shawnmckinney/apache-fortress-demo/issues/4#issuecomment-74329898 .

ussmith commented 9 years ago

From the consumer side the build.properties in core is a bit problematic. Every time I try to fetch and merge I either have to checkout or stash my local changes and then bring them back or I can't merge. I'd suggest making a build.properties.example and in the instructions have folks copy and modify a local version that's not part of the core repository. It would make updates significantly easier.

shawnmckinney commented 9 years ago

The core package has a build.properties file. It and fortress.properties.src combine to generate a fortress.properties file during the core's build, which is subsequently manually copied to the the other downstream projects, i.e. web, rest, demo. The others have that same properties file checked into their respestive git repos - hence the conflict.

Agree this is a problem. How would you do it? I could rename the file to fortress.properties.example in each of the sub-projects, and instruct the user copy it to fortress.properties as their first step (or just use the one from core). This would remove the conflict from source control - except for the original core build.property file which has same problem.

It's simple and that is usually best...but there is still conflict with that one file in core. Is there a better way?

On Mon, Feb 16, 2015 at 9:49 AM, Shawn Eion Smith notifications@github.com wrote:

From the consumer side the build.properties in core is a bit problematic. Every time I try to fetch and merge I either have to checkout or stash my local changes and then bring them back or I can't merge. I'd suggest making a build.properties.example and in the instructions have folks copy and modify a local version that's not part of the core repository. It would make updates significantly easier.

— Reply to this email directly or view it on GitHub https://github.com/shawnmckinney/apache-fortress-demo/issues/4#issuecomment-74528372 .

shawnmckinney commented 9 years ago

Taking a step further, also create a build.properties.example in core project, remove the former, build.properties, from control altogether and instruct user to copy it.

On Mon, Feb 16, 2015 at 10:09 AM, Shawn McKinney < shawn.michael.mckinney@gmail.com> wrote:

The core package has a build.properties file. It and fortress.properties.src combine to generate a fortress.properties file during the core's build, which is subsequently manually copied to the the other downstream projects, i.e. web, rest, demo. The others have that same properties file checked into their respestive git repos - hence the conflict.

Agree this is a problem. How would you do it? I could rename the file to fortress.properties.example in each of the sub-projects, and instruct the user copy it to fortress.properties as their first step (or just use the one from core). This would remove the conflict from source control - except for the original core build.property file which has same problem.

It's simple and that is usually best...but there is still conflict with that one file in core. Is there a better way?

On Mon, Feb 16, 2015 at 9:49 AM, Shawn Eion Smith < notifications@github.com> wrote:

From the consumer side the build.properties in core is a bit problematic. Every time I try to fetch and merge I either have to checkout or stash my local changes and then bring them back or I can't merge. I'd suggest making a build.properties.example and in the instructions have folks copy and modify a local version that's not part of the core repository. It would make updates significantly easier.

— Reply to this email directly or view it on GitHub https://github.com/shawnmckinney/apache-fortress-demo/issues/4#issuecomment-74528372 .

ussmith commented 9 years ago

Yeah, that's what I was suggesting. We generally try not to put anything that has to be configured directly in source control to avoid this kind of clash.

ussmith commented 9 years ago

I'd also add build.properties to .gitignore to prevent accidentally checking a copy in.

shawnmckinney commented 9 years ago

Made those changes you requested. I am now able to complete the fortress ten minute guide, in about 10 minutes.

That is after the README-TEN-MINUTE-GUIDE steps have been been completed (to stage source and build core) AND with the apache binaries staged as well.

The fortress demo takes around the same amount of time to complete. Right now I am happy with how these processes are looking. Your input has helped a great deal. Let me if there is anything else that you know of needing to be changed or added.

On Mon, Feb 16, 2015 at 1:26 PM, Shawn Eion Smith notifications@github.com wrote:

I'd also add build.properties to .gitignore to prevent accidentally checking a copy in.

— Reply to this email directly or view it on GitHub https://github.com/shawnmckinney/apache-fortress-demo/issues/4#issuecomment-74560030 .