2:55 p.m.
Are there any projects out there calling AS7 as part of their own testsuite?
AS7 is about to be secured by default so some minor changes are likely
to be needed to add a user to the AS7 installation and then make the
invocations as that user.
Within the AS7 testsuite we will have examples of the various calls into
the management interfaces with CallbackHandlers and Authenticators
handling this. If you can point me to where you project makes the calls
I can point you to the appropriate example in the AS7 testsuite.
Regards,
Darran Lofthouse.
1:35 p.m.
New subject: Unresolved issues with lock down by default
Ok so I merged the lock down patch after a clean integration run but
there are still some issues we need to resolve before releasing:
1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
1a) Once an invalid password is entred the server will not shutdown
cleanly, it hanges
2. The log message is too early and will go easily unnoticed
3. The web console doesnt tell you what to do
4. The digest tool doesnt actually edit the file for you (kind of a pain)
5. It would be nice if the CLI shell script could detect that the file
is empty and tell you what to do
I think we should modify the CLI to somehow tell you that you need to
run a password.
On 11/9/11 2:55 PM, Darran Lofthouse wrote:
Are there any projects out there calling AS7 as part of their own
testsuite?
AS7 is about to be secured by default so some minor changes are likely
to be needed to add a user to the AS7 installation and then make the
invocations as that user.
Within the AS7 testsuite we will have examples of the various calls into
the management interfaces with CallbackHandlers and Authenticators
handling this. If you can point me to where you project makes the calls
I can point you to the appropriate example in the AS7 testsuite.
Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
1:52 p.m.
New subject: Unresolved issues with lock down by default
Sure, although it's not actually the web console but the management web
server that needs to take action. If you type in an invalid password it
loops forever asking for your credentials. If you hit cancel you get a
blank screen. So the user has no idea what to do next.
What should happen is on an auth failure we should display a page
describing how to run the command to add a user account.
On 11/10/11 1:50 PM, Heiko Braun wrote:
Can elaborate on this? I didn't follow this thread.
Ike
On Nov 10, 2011, at 8:35 PM, Jason T. Greene wrote:
> 3. The web console doesnt tell you what to do
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
2:11 p.m.
New subject: Unresolved issues with lock down by default
On 11/10/2011 07:35 PM, Jason T. Greene wrote:
1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
1a) Once an invalid password is entred the server will not shutdown
cleanly, it hanges
I don't believe that issue is related to this change - entering an
invalid password used to correctly allow you to try and connect again -
this commit doesn't change any code in this area.
2:26 p.m.
New subject: Unresolved issues with lock down by default
On 11/10/11 2:11 PM, Darran Lofthouse wrote:
On 11/10/2011 07:35 PM, Jason T. Greene wrote:
> 1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
> 1a) Once an invalid password is entred the server will not shutdown
> cleanly, it hanges
I don't believe that issue is related to this change - entering an
invalid password used to correctly allow you to try and connect again -
this commit doesn't change any code in this area.
Yeah I think the problem is in the management protocol code. Although I
have not investigated it in details.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
2:23 p.m.
New subject: Unresolved issues with lock down by default
On 11/10/2011 07:35 PM, Jason T. Greene wrote:
2. The log message is too early and will go easily unnoticed
I can log a second message when they attempt to connect if they have not
added a user - for the first message I wanted to get something logged to
let them know the problem as soon as was possible.
3. The web console doesnt tell you what to do
I don't think it would be a big issue to intercept all requests to the
http interface and just redirect to a static HTML page with instructions.
After all on a first installation I would expect someone to be
connecting with a browser first before actually attempting to use a
different HTTP client.
1:22 a.m.
New subject: Unresolved issues with lock down by default
+1
makes sense.
On Nov 10, 2011, at 9:23 PM, Darran Lofthouse wrote:
> 3. The web console doesnt tell you what to do
I don't think it would be a big issue to intercept all requests to the
http interface and just redirect to a static HTML page with instructions.
4:48 a.m.
New subject: Unresolved issues with lock down by default
What's the strategy/status for Arquillian, Maven deploys, etc ? This affects quick
starts, tutorials etc. for the Beta launch.
I got mail from Darran on adding support for this in tools - not sure what we will be
able to do with so short warning.
But i'm interested in hearing what the others will be doing - do they even support
passing in username/passwords ?
…but now i'm truly happy we got Filesystem deployment "api" so I can
actually work without
users setting these things up - or will that also be disabled by default ?
/max
On Nov 10, 2011, at 20:35, Jason T. Greene wrote:
Ok so I merged the lock down patch after a clean integration run but
there are still some issues we need to resolve before releasing:
1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
1a) Once an invalid password is entred the server will not shutdown
cleanly, it hanges
2. The log message is too early and will go easily unnoticed
3. The web console doesnt tell you what to do
4. The digest tool doesnt actually edit the file for you (kind of a pain)
5. It would be nice if the CLI shell script could detect that the file
is empty and tell you what to do
I think we should modify the CLI to somehow tell you that you need to
run a password.
On 11/9/11 2:55 PM, Darran Lofthouse wrote:
> Are there any projects out there calling AS7 as part of their own testsuite?
>
> AS7 is about to be secured by default so some minor changes are likely
> to be needed to add a user to the AS7 installation and then make the
> invocations as that user.
>
> Within the AS7 testsuite we will have examples of the various calls into
> the management interfaces with CallbackHandlers and Authenticators
> handling this. If you can point me to where you project makes the calls
> I can point you to the appropriate example in the AS7 testsuite.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
7:22 a.m.
New subject: Unresolved issues with lock down by default
From the TorqueBox side of things I definitely don't want to tell
our users to create a username / password combo before they can deploy things. So, this
means either sticking with the file system deployments long-term or undoing this secure by
default in the TorqueBox distribution.
Ben
On Nov 11, 2011, at 5:48 AM, Max Rydahl Andersen wrote:
What's the strategy/status for Arquillian, Maven deploys, etc ? This affects quick
starts, tutorials etc. for the Beta launch.
I got mail from Darran on adding support for this in tools - not sure what we will be
able to do with so short warning.
But i'm interested in hearing what the others will be doing - do they even support
passing in username/passwords ?
…but now i'm truly happy we got Filesystem deployment "api" so I can
actually work without
users setting these things up - or will that also be disabled by default ?
/max
On Nov 10, 2011, at 20:35, Jason T. Greene wrote:
> Ok so I merged the lock down patch after a clean integration run but
> there are still some issues we need to resolve before releasing:
>
> 1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
> 1a) Once an invalid password is entred the server will not shutdown
> cleanly, it hanges
> 2. The log message is too early and will go easily unnoticed
> 3. The web console doesnt tell you what to do
> 4. The digest tool doesnt actually edit the file for you (kind of a pain)
> 5. It would be nice if the CLI shell script could detect that the file
> is empty and tell you what to do
>
> I think we should modify the CLI to somehow tell you that you need to
> run a password.
>
> On 11/9/11 2:55 PM, Darran Lofthouse wrote:
>> Are there any projects out there calling AS7 as part of their own testsuite?
>>
>> AS7 is about to be secured by default so some minor changes are likely
>> to be needed to add a user to the AS7 installation and then make the
>> invocations as that user.
>>
>> Within the AS7 testsuite we will have examples of the various calls into
>> the management interfaces with CallbackHandlers and Authenticators
>> handling this. If you can point me to where you project makes the calls
>> I can point you to the appropriate example in the AS7 testsuite.
>>
>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:37 a.m.
New subject: Unresolved issues with lock down by default
I don't think this is a problem for you guys because you replace
standalone.xml. As long as you don't include the auth section it will no
longer require auth.
On 11/11/11 7:22 AM, Benjamin Browning wrote:
> From the TorqueBox side of things I definitely don't want to
tell our users to create a username / password combo before they can deploy things. So,
this means either sticking with the file system deployments long-term or undoing this
secure by default in the TorqueBox distribution.
Ben
On Nov 11, 2011, at 5:48 AM, Max Rydahl Andersen wrote:
>
> What's the strategy/status for Arquillian, Maven deploys, etc ? This affects
quick starts, tutorials etc. for the Beta launch.
>
> I got mail from Darran on adding support for this in tools - not sure what we will
be
> able to do with so short warning.
>
> But i'm interested in hearing what the others will be doing - do they even
support passing in username/passwords ?
>
> …but now i'm truly happy we got Filesystem deployment "api" so I can
actually work without
> users setting these things up - or will that also be disabled by default ?
>
> /max
>
> On Nov 10, 2011, at 20:35, Jason T. Greene wrote:
>
>> Ok so I merged the lock down patch after a clean integration run but
>> there are still some issues we need to resolve before releasing:
>>
>> 1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
>> 1a) Once an invalid password is entred the server will not shutdown
>> cleanly, it hanges
>> 2. The log message is too early and will go easily unnoticed
>> 3. The web console doesnt tell you what to do
>> 4. The digest tool doesnt actually edit the file for you (kind of a pain)
>> 5. It would be nice if the CLI shell script could detect that the file
>> is empty and tell you what to do
>>
>> I think we should modify the CLI to somehow tell you that you need to
>> run a password.
>>
>> On 11/9/11 2:55 PM, Darran Lofthouse wrote:
>>> Are there any projects out there calling AS7 as part of their own testsuite?
>>>
>>> AS7 is about to be secured by default so some minor changes are likely
>>> to be needed to add a user to the AS7 installation and then make the
>>> invocations as that user.
>>>
>>> Within the AS7 testsuite we will have examples of the various calls into
>>> the management interfaces with CallbackHandlers and Authenticators
>>> handling this. If you can point me to where you project makes the calls
>>> I can point you to the appropriate example in the AS7 testsuite.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Jason T. Greene
>> JBoss AS Lead / EAP Platform Architect
>> JBoss, a division of Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
8:40 a.m.
New subject: Unresolved issues with lock down by default
On 11/11/11 4:48 AM, Max Rydahl Andersen wrote:
…but now i'm truly happy we got Filesystem deployment
"api" so I can actually work without
users setting these things up - or will that also be disabled by default ?
You keep saying this, but doesn't this feel a little bit ironic to you?
I mean you were constantly demanding a management API, and now that we
have one you can't stop looking for ways not to use it.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
8:50 a.m.
New subject: Unresolved issues with lock down by default
On Nov 11, 2011, at 15:40, Jason T. Greene wrote:
On 11/11/11 4:48 AM, Max Rydahl Andersen wrote:
> …but now i'm truly happy we got Filesystem deployment "api" so I can
actually work without
> users setting these things up - or will that also be disabled by default ?
You keep saying this, but doesn't this feel a little bit ironic to you? I mean you
were constantly demanding a management API, and now that we have one you can't stop
looking for ways not to use it.
I never demanded a management api that couldn't be used for incremental deployments -
I also never wanted one for deployments if it required full access to a running server.
I did demand a File API so I knew I could actually interact with a local server no matter
if it is running or not and from *any* tool that already exist with or without management
api available.
The thing we like management API for is to check server is running, graceful shutdown and
to query for status of things.
Doing simple things like deploying app, datasource and queues should be doable without a
lot of overhead.
It's great the management API can do it but with it now being default secured even for
127.0.0.1/localhost its not the first thing I would use.
Note, we will make this easy to use, but for the cases of server not running during
deployment (local setup, preparation of a server, you don't want to have it running
etc.) or the management
API not being available (OpenShift and others and just plain remote server which only
exposes SSH/SCP) there the File API is tremendously useful.
And its much more universal.
/max
http://about.me/maxandersen
9:24 a.m.
New subject: Unresolved issues with lock down by default
On 11/11/11 8:50 AM, Max Rydahl Andersen wrote:
On Nov 11, 2011, at 15:40, Jason T. Greene wrote:
> On 11/11/11 4:48 AM, Max Rydahl Andersen wrote:
>> …but now i'm truly happy we got Filesystem deployment "api" so I
>> can actually work without users setting these things up - or will
>> that also be disabled by default ?
>
> You keep saying this, but doesn't this feel a little bit ironic to
> you? I mean you were constantly demanding a management API, and now
> that we have one you can't stop looking for ways not to use it.
I never demanded a management api that couldn't be used for
incremental deployments - I also never wanted one for deployments if
it required full access to a running server.
I did demand a File API so I knew I could actually interact with a
local server no matter if it is running or not and from *any* tool
that already exist with or without management api available.
I believe the words you used were "REST API". Normally I wouldn't say
anything, but I'm a little tired of this repeated "dig".
The thing we like management API for is to check server is running,
graceful shutdown and to query for status of things.
Doing simple things like deploying app, datasource and queues should
be doable without a lot of overhead.
It's great the management API can do it but with it now being default
secured even for 127.0.0.1/localhost its not the first thing I would
use.
Note, we will make this easy to use, but for the cases of server not
running during deployment (local setup, preparation of a server, you
don't want to have it running etc.) or the management API not being
available (OpenShift and others and just plain remote server which
only exposes SSH/SCP) there the File API is tremendously useful.
And its much more universal.
Yes we all know your opinion. Honestly I don't care whether you use it
or not, but it's never going to do more than drop deployments in
standalone mode.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11:16 a.m.
New subject: Unresolved issues with lock down by default
> I did demand a File API so I knew I could actually interact with
a
> local server no matter if it is running or not and from *any* tool
> that already exist with or without management api available.
I believe the words you used were "REST API". Normally I wouldn't say
anything, but I'm a little tired of this repeated "dig".
Just to be clear - for me the management API was not about making it the
exclusive way to communicate to the server because it has obvious issues
when the server isn't running or doesn't have that API available or tools
doesn't have the capability to talk to the api.
I honestly wasn't trying to "dig" on this - I just want to point out that
the File API
makes the impacts of this for user much less.
Just wanted to know what the status is for the tools that as far as I'm aware
primarily the deployment API.
i.e. maven deploy plugin / arquillian especially and how it affects the
quickstarts/examples.
Anyone knows the answer to those ?
> Note, we will make this easy to use, but for the cases of server
not
> running during deployment (local setup, preparation of a server, you
> don't want to have it running etc.) or the management API not being
> available (OpenShift and others and just plain remote server which
> only exposes SSH/SCP) there the File API is tremendously useful.
>
> And its much more universal.
Yes we all know your opinion. Honestly I don't care whether you use it
or not, but it's never going to do more than drop deployments in
standalone mode.
Never asked for more and to be clear we *are* using the API but trying
to avoid it be a requirement to get started.
/max
http://about.me/maxandersen
3:25 p.m.
New subject: Unresolved issues with lock down by default
On 11/10/11 1:35 PM, Jason T. Greene wrote:
Ok so I merged the lock down patch after a clean integration run but
there are still some issues we need to resolve before releasing:
1. The CLI hangs if you enter an invalid name/password ONCE (oops!)
1a) Once an invalid password is entred the server will not shutdown
cleanly, it hanges
This one is now solved.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
7:18 a.m.
TorqueBox fires up AS7 and executes some management operations as part of its testsuite.
Relevant (Ruby) code here:
https://github.com/torquebox/torquespec/blob/master/lib/torquespec/as7.rb
Any pointers on how we'll need to adapt our starting of AS7 and management operations
would be great.
Ben
On Nov 9, 2011, at 3:55 PM, Darran Lofthouse wrote:
Are there any projects out there calling AS7 as part of their own
testsuite?
AS7 is about to be secured by default so some minor changes are likely
to be needed to add a user to the AS7 installation and then make the
invocations as that user.
Within the AS7 testsuite we will have examples of the various calls into
the management interfaces with CallbackHandlers and Authenticators
handling this. If you can point me to where you project makes the calls
I can point you to the appropriate example in the AS7 testsuite.
Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4791
days inactive
4793
days old
16 comments
6 participants
participants (6)
-
Benjamin Browning -
Darran Lofthouse -
Darran Lofthouse -
Heiko Braun -
Jason T. Greene -
Max Rydahl Andersen