Local Search for the Admin Console
by Harald Pehl
During the F2F meeting in Brno Heiko and I started a little experiment: Local search for the Admin Console. The idea is to have a search index in the browser's local storage which is used to enable a "search as you type" feature.
With the introduction of RBAC, all views were annotated with resource addresses. We reuse this information to setup an index over those addresses. The description of the r-r-d operation is extracted, tokenized and stored in the index. In addition it's possible to programmatically assign keywords to selected views. Keywords are a way to boost views in the search results. We did that for prominent views like the deployment browser.
The index is built lazily when the user enters the search for the first time. In a typical environment this takes only a few seconds. Once the index is ready, it is stored in the local storage using the language, the operation mode (standalone / domain) and the model version as key. The size of the index is about 70 KB (for domain mode).
Under the hood the index is built using [1]. As a little extra you can reach the local search using a shortcut (Cmd+. / Ctrl+.) - therefore [2] is used.
I found some time to polish the local search and am quite happy with the result. I'd like to add this feature to WildFly 8.0.1. If you want to take a look, grab the latest snapshot from [3] and replace the default console resources under <WF_HOME>/modules/system/layers/base/org/jboss/as/console/main/.
What do you think?
[1] https://github.com/olivernn/lunr.js
[2] https://github.com/ccampbell/mousetrap
[3] https://repository.jboss.org/nexus/service/local/artifact/maven/redirect?...
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
11 years, 11 months
Thoughts on alternative security managers
by David M. Lloyd
It is possible to implement a security manager which behaves differently
than the default AccessController-based security manager. I am
wondering if we should maybe explore some options here.
AccessControlContext (ACC) permission checks are expensive. The
assembled context can consist of many object instances, many of which
may be constructed on the fly, in order to check a permission against
every invocation frame on the call stack (including going through thread
start points to earlier, snapshotted thread stacks) down to the most
recent doPrivileged() invocation. The theory is to ensure that
permissions can never escalate without an explicit action. However, few
frameworks use doPrivileged() properly, resulting in too many
permissions being assigned to the user deployment anyway.
Option 0: Status quo
--------------------
To mitigate some of this cost, our current security manager has
"checked" and "unchecked" modes for the current thread. When running
trusted code, we switch to "unchecked" mode which is functionally
similar to a privileged block, except (a) it is much faster as expensive
permission checks are simply bypassed and (b) it is the responsibility
of the container to ensure that checked mode is re-enabled before
calling back in to user code.
When checked mode is enabled, all permission checks happen in the usual
way with ACC. Privileged blocks are necessary for code that runs in
checked mode (i.e. user libraries and many of our APIs that do not have
direct support for WildFlySecurityManager).
Option 1: Fast and simple
-------------------------
We could completely switch the SecurityManager's (SM's) security context
object to be a per-deployment context of some sort. Permissions would
be checked based on whatever deployment is currently active; checked and
unchecked modes would still be used in this case.
In this option, the permissions that are currently checked are *always*
the active deployment, which is particularly relevant in the case that
the deployment calls into some other deployment without using container
facilities.
We could still support standard security policies to assign additional
permissions to the current Principal.
Privileged blocks in this case would be completely ignored.
This could be a very fast approach as no objects need be constructed to
perform a permission check; however, it is also perhaps harder to create
fine-grained restrictions on things.
Option 2: Call stack (simplified version)
-----------------------------------------
Alternatively, we could examine the call stack on each invocation to
locate the most recent enclosing "untrusted" class loader. This
involves acquiring and traversing the invocation call stack (which may
be cheaper in Java 8 or 9). While expensive, this operation should be
less expensive than constructing an ACC.
Privileged blocks in this case would also be completely ignored, and all
the other above benefits would hold. For the relative performance cost
we would pay over Option 1, we'd regain the ability to establish
fine-grained restrictions.
Option 3: Call stack (advanced version)
---------------------------------------
In this option we essentially duplicate what ACC does, but using the
presumably less-expensive SM method of acquiring and examining the call
stack. Privileged blocks probably would not work, but if not, we'd have
an alternative mechanism for establishing bounds on the set of
permissions to check per call. We would still support checked/unchecked
mode.
All three of these options would not be compatible with DomainCombiners,
if that matters.
Any thoughts?
--
- DML
11 years, 11 months
inheriting security domain
by Bill Burke
I noticed that if you define a WAR's security domain and then define an
EJB within WEB-INF/classes, that EJB's default security domain is
"other" and not the WAR's security domain.
Don't you think it would be more user friendly and intuitive for nested
components' security domain to be inherited from their parent container
rather than defaulting to "other"?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
Re: [wildfly-dev] [jboss-as7-dev] Domain mode server launch command
by Brian Stansberry
Hi John,
I copied the wildfly-dev list.
I prefer the <jvm> approach. We already have logic for combining jvm
configs set at different levels (server-group, host, server) so people
can set this at whatever level they prefer, and then if they want
something different for a particular server they can override.
Cheers,
- Brian
On 3/7/14, 4:15 AM, John O'Hara wrote:
> Brian,
>
> I was talking to Kabir about incorporating this feature into the
> host-controller model. We discussed different options for places to
> define the launch command, and we came to the conclusion that it could
> be placed in one of two locations in host.xml. The options discussed were;
>
> 1. Incorporate the command as an attribute of the existing <jvm>
> element. This would allow for the same lanuch command to be applied
> to all servers in the domain and only have to define it once e.g.
> running the server process under a different user id. The launch
> command can also be overwritten or defined for each server allowing
> separate launch commands for each server e.g. pinning jvm to
> particular numa nodes.
> 2. Creating a new <server-launch-command> element under the <server>
> elements. Users would need to define the server launch command for
> each server separately.
>
> I had originally defined the host schema with a <server-launch-command>
> element under the <server>element. However, it might provide more
> flexibility to define the launch command in the <jvm> element.
>
> Kabir suggested that I run this by you, so your thoughts on where to
> define this in hosts.xml would be greatly appreciated.
>
> Thanks
>
> John
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11 years, 11 months
Clustering with CLIENT-CERT auth Jaas
by Cristiano Andrade
Hi,
Someone here already configured a Wildfly cluster with client-cert auth ?
I tried, but no sucess, wildfly always throw a 403 http message on first
request. When I press f5 it works.
Tks
Cristiano
11 years, 12 months
Clustering in WildFly 8
by Arun Gupta
I've started playing with clustering in WildFly 8 and been able to
create a simple sample that shows HTTP session failover.
The sample is at:
https://github.com/arun-gupta/wildfly-samples/tree/master/clustering/http
I'll be sharing a blog post on this soon.
In the mean while here is some initial feedback:
1). Starting domain.sh automatically starts two WildFly instances on
8080 and 8230. Clicking on "Administration Console" shows the message
" if you are running a domain the http interface can not be
automatically detected so check the host.xml configuration and connect
directly.".
I think this message can be improved by saying what needs to be done
in order to access the console.
2). If a WildFly instance needs to run on multiple hosts then it seems
like it needs to be manually copied over to each machine. Is there a
mechanism where a zip bundle can be sftp/ssh copied over to the remote
machine ? This would simplify setting up a cluster.
3). Changed server-two auto-start="false" and server-three
auto-start="true". Running domain.sh gives the following error:
[Server:server-three] 15:17:03,924 INFO [org.jboss.messaging] (MSC
service thread 1-12) JBAS011615: Registered HTTP upgrade for
hornetq-remoting protocol handled by http-acceptor-throughput acceptor
[Server:server-three] 15:17:03,978 ERROR [org.hornetq.core.server]
(Thread-0 (HornetQ-scheduled-threads-45430818)) HQ224033: Failed to
broadcast connector configs: java.io.IOException: Can't assign
requested address
[Server:server-three] at java.net.PlainDatagramSocketImpl.send(Native
Method) [rt.jar:1.7.0_45]
[Server:server-three] at
java.net.DatagramSocket.send(DatagramSocket.java:676)
[rt.jar:1.7.0_45]
[Server:server-three] at
org.hornetq.api.core.UDPBroadcastGroupConfiguration$UDPBroadcastEndpoint.broadcast(UDPBroadcastGroupConfiguration.java:135)
[hornetq-core-client-2.4.1.Final.jar:]
[Server:server-three] at
org.hornetq.core.server.cluster.impl.BroadcastGroupImpl.broadcastConnectors(BroadcastGroupImpl.java:215)
[hornetq-server-2.4.1.Final.jar:]
[Server:server-three] at
org.hornetq.core.server.cluster.impl.BroadcastGroupImpl.run(BroadcastGroupImpl.java:227)
[hornetq-server-2.4.1.Final.jar:]
[Server:server-three] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[rt.jar:1.7.0_45]
Is there something else that needs to be configured ?
Thanks
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
11 years, 12 months
smaller footprints
by Bill Burke
On Resteasy list I have a few people "rolling their own app server"
using Netty, Weld, Resteasy and JPA. I asked one of them "I don't
understand why you are rolling your own app server" response:
"It's actually a lot more lightweight. The minimum I can run the
equivalent on AS7 on is ~ 180 mb in binaries, but throwing this
together is about 32 mb (and compresses further when its packaged).
I'm able to start the JVM on the bare minimum (~100mb on my linux VM)
but AS7 with all I need is about 756mb. When rolling out in the
cloud, where all of my REST APIs are stateless, running with this
configuration helps us get a lot more per node."
I'm not complaining :), just something to think about. It might be
really valuable to focus a bit in Wildfly 9 to make it easier to create
custom profiles or even different packaging options for the app server
instead of the exploded style we currently have.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 12 months
