Skip to main content

Home/ Groups/ SoftwareEngineering
kuni katsuya

Chapter 6. Messaging (Gravity) - 0 views

  • Granite Data Services provides a messaging feature, code name Gravity, implemented as a Comet-like service with AMF3 data polling over HTTP (producer/consumer based architecture)
  • GraniteDS messaging relies on two main AS3 components on the Flex side: org.granite.gravity.Consumer and org.granite.gravity.Producer
  • 6.3. Common Configuration There are three main steps to configure Gravity in an application: Declare the Gravity servlet implementation for your target server in web.xml Declare a messaging service and destination in services-config.xml, mapped to a specific channel definition of type GravityChannel
  • ...10 more annotations...
  • org.granite.gravity.tomcat.GravityTomcatServlet
  • /gravityamf/*
  • 6.3.1. Supported Application Servers
  • GraniteDS provides a generic servlet implementation that can work in any compliant servlet container
  • blocking IO and thus will provide relatively limited scalability
  • GraniteDS thus provides implementations of non blocking messaging for the most popular application servers.
  • asynchronous non blocking servlets
  • JBoss 5+org.granite.gravity.jbossweb.GravityJBossWebServletOnly with APR/NIO enabled (APR highly recommended)
  • GlassFish 3.xorg.granite.gravity.async.GravityAsyncServletUsing Servlet 3.0
  • Tomcat 7.x / Jetty 8.xorg.granite.gravity.async.GravityAsyncServletUsing Servlet 3.0
kuni katsuya

Chapter 10. Integration with CDI - 0 views

  • 10.3.5. Security GraniteDS provides a client-side component named identity that ensures the integration between the client RemoteObject credentials and the server-side container security. It additionally includes an easy-to-use API to define runtime authorization checks on the Flex UI.
  • CDI identity component (of class org.granite.tide.cdi.Identity) predictably provides two methods login() and logout()
  • identity component is integrated with server-side role-based security and can be used to get information or show/hide UI depending on the user access rights:
  • ...2 more annotations...
  •  enabled="{identity.hasRole('admin')}"
  • button labeled Delete will be enabled only if the user has the role admin
kuni katsuya

Chapter 9. Integration with Seam 2.2 - 0 views

  • 9.2.6. Integration with Seam Security
  • When not using the Seam native setup, you have to manually configure the integration of Seam Security in granite-config.xml.
  • <granite-config>    ...    <!--     ! Use Seam 2.1+ based security service.     !-->     <security type="org.granite.seam21.security.Seam21SecurityService"/> </granite-config>
kuni katsuya

Seam - Contextual Components - 0 views

  • 15.6. Authorization
  • Seam Security is built around the premise of users being granted roles and/or permissions, allowing them to perform operations that may not otherwise be permissible for users without the necessary security privileges
  • 15.6.1. Core concepts
  • ...15 more annotations...
  • 15.6.1.1. What is a role? A role is a group, or type, of user that may have been granted certain privileges for performing one or more specific actions within an application
  • used to create logical groups of users for the convenient assignment of specific application privileges
  • 15.6.1.2. What is a permission? A permission is a privilege (sometimes once-off) for performing a single, specific action. It is entirely possible to build an application using nothing but permissions, however roles offer a higher level of convenience when granting privileges to groups of users
  • consisting of three "aspects";
  • a target
  • an action
  • a recipient
  • An empty @Restrict implies a permission check of componentName:methodName
  • implied permission required to call the delete() method is account:delete
  • equivalent of this would be to write @Restrict("#{s:hasPermission('account','delete')}")
  • @Restrict annotation may reference any objects that exist within a Seam context. This is extremely useful when performing permission checks for a specific object instance.
  • selectedAccount
  • selectedAccount
  •  Identity.instance().checkRestriction
  • If the expression specified doesn't evaluate to true, either if the user is not logged in, a NotLoggedInException exception is thrown or if the user is logged in, an AuthorizationException exception is thrown.
kuni katsuya

Application Security With Apache Shiro - 0 views

  • previously known as the JSecurity project
  • The word Subject is a security term that basically means "the currently executing user"
  • Core Concepts: Subject, SecurityManager, and Realms
  • ...12 more annotations...
  • Subject
  • 'Subject' can mean a human being, but also a 3rd party process, daemon account, or anything similar. It simply means 'the thing that is currently interacting with the software'
  • Subject currentUser = SecurityUtils.getSubject();
  • SecurityManager
  • SecurityManager manages security operations for all users
  • Realms
  • Realm acts as the ‘bridge’ or ‘connector’ between Shiro and your application’s security data. That is, when it comes time to actually interact with security-related data like user accounts to perform authentication (login) and authorization (access control), Shiro looks up many of these things from one or more Realms configured for an application.
  • Realm is essentially a security-specific DAO
  • Shiro provides out-of-the-box Realms to connect to a number of security data sources (aka directories) such as LDAP, relational databases (JDBC), text configuration sources like INI and properties files, and more
  • Authorization
  • A permission is a raw statement of functionality, for example ‘open a door’, ‘create a blog entry’, ‘delete the ‘jsmith’ user’, etc. By having permissions reflect your application’s raw functionality, you only need to change permission checks when you change your application’s functionality. In turn, you can assign permissions to roles or to users as necessary at runtime.
  • “Run As” support for assuming the identity of another Subject
kuni katsuya

ICW Developer Network - 0 views

  • ComparisonThis section provides a brief comparison of SAFs functionality with that of the Acegi Security Framework [11] and JBoss Seam Security [12]
  • Acegi’s Policy Decision functionality is not based on Java security standards but on a proprietary solution
  • ACL defines per domain object who has access permissions
  • ...5 more annotations...
  • Both Acegi as well as SAF use AspectJ and Spring AOP for Policy Enforcement
  • JBoss Seam follows a different process when implementing Policy Decision functionality and sets access rules with the help of JBoss Rules [13] the JBoss rules engine
  • access decision to the domain objects in an application can be based on any number of complex rules
  • @Restrict annotations
  • 07.2007
kuni katsuya

Seam Framework - Maven Artifacts - 0 views

  • adding this profile to your settings.xml
  • Seam 3 modules and examples are published to the JBoss Community Maven Repository when they are released
  • <url>http://repository.jboss.org/nexus/content/groups/public</url>
  • ...1 more annotation...
  • <url>http://repository.jboss.org/nexus/content/groups/public</url>
kuni katsuya

Admin Guide - JBoss AS 7.1 - Project Documentation Editor - 0 views

  • Deployment of -ds.xml files
  • Starting with JBoss Application Server 7.1.0.Final you have the ability to deploy a -ds.xml file following the schema: http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd It is mandatory to use a reference to an already deployed / defined <driver> entry.
« First ‹ Previous 801 - 820 of 1272 Next › Last »
Showing 20 items per page