Skip to main content

Home/ SoftwareEngineering/ Group items tagged resources

Rss Feed Group items tagged

kuni katsuya

JdbcRealm (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Class JdbcRealm
  • Realm that allows authentication and authorization via JDBC calls
  • subclassed and the appropriate methods overridden. (usually doGetAuthenticationInfo(org.apache.shiro.authc.AuthenticationToken), getRoleNamesForUser(java.sql.Connection,String), and/or getPermissions(java.sql.Connection,String,java.util.Collection)
kuni katsuya

RolePermissionResolver (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Interface RolePermissionResolver
  • RolePermissionResolver resolves a String value and converts it into a Collection of Permission instances
  • resolve the roles into permissions
    • kuni katsuya
       
      Role is just a collection of Permissions
kuni katsuya

AuthorizingRealm (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Class AuthorizingRealm
  • An AuthorizingRealm extends the AuthenticatingRealm's capabilities by adding Authorization (access control) support
  • perform all role and permission checks automatically (and subclasses do not have to write this logic) as long as the getAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) method returns an AuthorizationInfo
  • ...3 more annotations...
  • AuthorizationInfo getAuthorizationInfo(PrincipalCollection principals)
  • Returns an account's authorization-specific information for the specified principals, or null if no account could be found
  • automatically perform access control checks for the corresponding Subject
kuni katsuya

Realm (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Interface Realm
  • AuthenticatingRealm
  • AuthorizingRealm
  • ...7 more annotations...
  • JdbcRealm
  • A Realm is a security component that can access application-specific security entities such as users, roles, and permissions to determine authentication and authorization operations
  • security-specific DAOs
  • If for some reason you don't want your Realm implementation to perform authentication duties, you should override the supports(org.apache.shiro.authc.AuthenticationToken) method to always return false
  • does not require you to implement or extend any User, Group or Role interfaces or classes
  • Shiro tries to maintain a non-intrusive development philosophy
  • Most users will not implement the Realm interface directly, but will extend one of the subclasses, AuthenticatingRealm or AuthorizingRealm, greatly reducing the effort requird to implement a Realm from scratch
kuni katsuya

AuthorizationInfo (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Interface AuthorizationInfo
  • AuthorizationInfo represents a single Subject's stored authorization data (roles, permissions, etc) used during authorization (access control) checks only
  • Roles are represented as a Collection of Strings (Collection<String>)
  • ...3 more annotations...
  • Permissions are provided in two ways: A Collection of Strings, where each String can usually be converted into Permission objects by a Realm's PermissionResolver A Collection of Permission objects
  • most Realms store both sets of data for a Subject
  • a Realm implementation to utilize an implementation of the Account interface instead, which is a convenience interface that combines both AuthenticationInfo and AuthorizationInfo
kuni katsuya

AuthenticationInfo (Apache Shiro :: Core 1.1.0 API) - 0 views

  • Interface AuthenticationInfo
  • AuthenticationInfo represents a Subject's (aka user's) stored account information relevant to the authentication
  • difference between this interface and the AuthenticationToken interface.
  • ...7 more annotations...
  • AuthenticationToken
  • represents data submitted for any given login attempt
  • AuthenticationInfo
  • implementations represent already-verified and stored account data
  • Since Shiro sometimes logs authentication operations, please
  • ensure your AuthenticationInfo's toString() implementation does not print out account credentials (password, etc)
  • as these might be viewable to someone reading your logs
kuni katsuya

Java EE 7 Roadmap (The Aquarium) - 0 views

  • Java EE 7 Roadmap
  • support for use in cloud environments
  • Web Sockets
  • ...19 more annotations...
  • JSON-P
  • we believe that providing solid support for standardized PaaS-based programming and multi-tenancy would delay the release of Java EE 7 until the spring of 2014
  • way too long
  • defer the remaining aspects of our agenda for PaaS enablement and multi-tenancy support to
  • Java EE 8
  • already laid some of the infrastructure for cloud support in Java EE 7
  • resource definition metadata
  • improved security configuration
  • JPA schema generation
  • Java EE 8 Platform release for the
  • spring of 2015
  • support for HTML 5 in the form of Web Sockets
  • JSON-P
  • simplified JMS 2.0 APIs
  • improved Managed Bean alignment, including
  • transactional interceptors
  • JAX-RS 2.0 client API
  • method-level validation
  • more comprehensive expression language
kuni katsuya

Mirror/deltaspike at master · DeltaSpike/Mirror · GitHub - 0 views

  • CDI Extensions Project
  • best mature features of
  • JBoss Seam3
  • ...27 more annotations...
  • Apache MyFaces CODI
  • other CDI Extensions projects.
  • container agnostic
  • different containers get activated via
  • Maven Profiles
  • CDI container integration via
  • Arquillian
  • Building Apache DeltaSpike
  • DeltaSpike-0.3
  • Release Notes
  • [DELTASPIKE-62] - Discuss security module
  • [DELTASPIKE-74] - unit and integration tests for @Secured
  •  [DELTASPIKE-75] - documentation for @Secured
  • [DELTASPIKE-78] - review and discuss Authentication API
  •  [DELTASPIKE-77] - review and discuss Identity API
  • [DELTASPIKE-79] - review and discuss Authorization API
  • [DELTASPIKE-81] - review and discuss Identity Management
  • [DELTASPIKE-82] - review and discuss external authentication
  • [DELTASPIKE-176] - unit and integration tests for @Transactional
  • [DELTASPIKE-177] - documentation for @Transactional
  •  [DELTASPIKE-179] - unit and integration tests for @TransactionScoped
  • [DELTASPIKE-175] - @Transactional for EntityTransaction
  •  [DELTASPIKE-178] - @TransactionScoped
  •  [DELTASPIKE-190] - Create ConfigurableDataSource
  • [DELTASPIKE-219] - @Transactional for JTA UserTransaction
  • [DELTASPIKE-230] - Fallback stragtegy for resource bundles and locales
  •   [DELTASPIKE-223] - Add convention for @MessageResource annotated types.
kuni katsuya

Comparing JSF Beans, CDI Beans and EJBs | Andy Gibson - 0 views

  • differences between CDI beans and EJBs is that EJBs are : Transactional Remote or local Able to passivate stateful beans freeing up resources Able to make use of timers Can be asynchronous
  • Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests
  • Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of
  • ...15 more annotations...
  • Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.
  • CDI beans can be injected into EJBs and EJBs can be injected into CDI beans
  • When to use which bean How do you know when to use which bean? Simple.
  • In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, its simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner
  • Comparing JSF Beans, CDI Beans and EJBs
  • JSF Managed Beans
  • In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.
  • JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.
  • CDI Beans
  • includes a complete, comprehensive managed bean facility
  • interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods
  • JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation
  • Comparing JSF Beans, CDI Beans and EJBs
  • Comparing JSF Beans, CDI Beans and EJBs
  • JSF Managed Beans
kuni katsuya

Chapter 5. AS3 Code Generator - 0 views

  • 5.2. Generated ActionScript 3 Classes
  • Gas3 uses the principle of "Base" and customizable inherited classes that let you add methods to generated classes without facing the risk of losing them when a new generation process is executed
  • 5.3. Java Classes and Corresponding Templates
  • ...13 more annotations...
  • summary of templates used by the generator depending on the kind of Java class it encounters:
  • these templates are bundled in the granite-generator.jar archive, in the org.granite.generator.template package and accessible as resources via the class loader
  • class: protocol is used because all standard templates are available in the classpath
  • Alternatively, you may use the file: protocol to load your template from the filesystem. These templates can be specified either by using absolute paths (eg. file:/absolute/path/to/mytemplate.gsp) or paths relative to your current Eclipse project root directory (eg. path/to/mytemplate.gsp).
  • ActionScript 3 generator is able to write AS3 typed client proxies for exposed remote services
  • Compared to the usual Flex RemoteObject, this can greatly help development by bringing
  • auto-completion
  • improved type-safety
  • in Flex when using remote services.
  • replicate validation annotations in order to use the Flex side validation framework
  •  Known Limitations
  • Gas3 does not support inner classes
  • must declare your classes in separated source files if you want them to be correctly handled by the generator
kuni katsuya

Permissions | Apache Shiro - 0 views

  • Permission as a statement that defines an explicit behavior or action
  • lowest-level constructs in security polices
  • explicitly define only "what" the application can do
  • ...69 more annotations...
  • do not at all describe "who" is able to perform the action(s)
  • Multiple Parts
  • Wildcard Permissions support the concept of multiple levels or parts. For example, you could restructure the previous simple example by granting a user the permission printer:query
  • Multiple Values Each part can contain multiple values. So instead of granting the user both the "printer:print" and "printer:query" permissions, you could simply grant them one: printer:print,query
  • All Values What if you wanted to grant a user all values in a particular part? It would be more convenient to do this than to have to manually list every value. Again, based on the wildcard character, we can do this. If the printer domain had 3 possible actions (query, print, and manage), this: printer:query,print,manage
  • simply becomes this: printer:*
  • Using the wildcard in this way scales better than explicitly listing actions since, if you added a new action to the application later, you don't need to update the permissions that use the wildcard character in that part.
  • Finally, it is also possible to use the wildcard token in any part of a wildcard permission string. For example, if you wanted to grant a user the "view" action across all domains (not just printers), you could grant this: *:view Then any permission check for "foo:view" would return true
  • Instance-Level Access Control
  • instance-level Access Control Lists
  • Checking Permissions
  • SecurityUtils.getSubject().isPermitted("printer:print:lp7200")
  • printer:*:*
  • all actions on a single printer
  • printer:*:lp7200
    • kuni katsuya
       
      note: wildcard * usage for 'actions' part
  • missing parts imply that the user has access to all values corresponding to that part
  • printer:print is equivalent to printer:print:*
  • Missing Parts
  • rule of thumb is to
  • use the most specific permission string possible
  • when performing permission checks
  • first part is the
  • domain
    • kuni katsuya
       
      aka 'resource'
  • that is being operated on (printer)
  • second part is the
  • action
  • (query) being performed
  • There is no limit to the number of parts that can be used
  • three parts - the first is the
  • domain
  • the second is the
  • action(s)
  • third is the
  • instance(s)
  • allow access to
  • all actions
  • all printers
  • can only leave off parts from the end of the string
  • Performance Considerations
  • runtime implication logic must execute for
  • each assigned Permission
  • implicitly using Shiro's default
  • WildcardPermission
  • which executes the necessary implication logic
  • When using permission strings like the ones shown above, you're
  • Shiro's default behavior for Realm
  • for every permission check
  • all of the permissions assigned to that user
  • need to be checked individually for implication
  • as the number of permissions assigned to a user or their roles or groups increase, the time to perform the check will necessarily increase
  • If a Realm implementor has a
  • more efficient way of checking permissions and performing this implication logic
  • Realm isPermitted* method implementations
  • should implement that as part of their
  • implies
  • user:*:12345
  • user:update:12345
  • printer
  • implies
  • printer:print
  • Implication, not Equality
  • permission
  • checks
  • are evaluated by
  • implication
  • logic - not equality checks
  • the former implies the latter
  • superset of functionality
  • implication logic can be executed at runtime
kuni katsuya

Spring vs Java EE Web Dev: Using Shiro for Authorization via CDI Interceptors then Easi... - 1 views

  • Using Shiro for Authorization via CDI Interceptors then Easily Test with Arquillian Did you know Apache Shiro is an easy-to-use security
  • @Secured @NamedResource("contact")
  • Interceptors will be ignored by CDI container unless it is listed in beans.xml
  • ...2 more annotations...
  • Tells the security interceptor to check the permission using "contact" as the resource name, not "contactmanager" inflected from the class name ContactManager
  • @NamedResource("contact")
kuni katsuya

MySQL :: MySQL 5.5 Reference Manual :: 13.7.5.32 SHOW PROFILES Syntax - 0 views

  • 13.7.5.32. SHOW PROFILES Syntax
  • SHOW PROFILE [type [, type] ... ] [FOR QUERY n] [LIMIT row_count [OFFSET offset]]
  • The SHOW PROFILES and SHOW PROFILE statements display profiling information that indicates resource usage for statements executed during the course of the current session.
  • ...1 more annotation...
  • Profiling is enabled by setting profiling to 1 or ON: mysql> SET profiling = 1;
kuni katsuya

DataSource configuration - JBoss AS 7.0 - Project Documentation Editor - 0 views

kuni katsuya

Session Management Cheat Sheet - OWASP - 0 views

  • Session Management Cheat Sheet
  • should not be extremely descriptive nor offer unnecessary details
  • change the default session ID name of the web development framework to a generic name
  • ...50 more annotations...
  • length must be at least 128 bits (16 bytes)
  • Session ID Length
  • Session ID Name Fingerprinting
  • Session ID Properties
  • Session ID Entropy
  • must be unpredictable (random enough) to prevent guessing attacks
  • good PRNG (Pseudo Random Number Generator) must be used
  • must provide at least 64 bits of entropy
  • Session ID Content (or Value)
  • content (or value) must be meaningless
  • identifier on the client side
  • meaning and business or application logic associated to the session ID must be stored on the server side
  • session objects or in a session management database or repository
  • create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
  • Session Management Implementation
  • defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID
  • token expiration date and time
  • This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods
  • Transport Layer Security
  • use an encrypted HTTPS (SSL/TLS) connection for the entire web session
  • not only for the authentication
  • process where the user credentials are exchanged.
  • “Secure” cookie attribute
  • must be used to ensure the session ID is only exchanged through an encrypted channel
  • never switch a given session from HTTP to HTTPS, or viceversa
  • should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute)
  • should not offer public unencrypted contents and private encrypted contents from the same host
  • www.example.com over HTTP (unencrypted) for the public contents
  • secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist)
  • only has port TCP/80 open
  • only has port TCP/443 open
  • “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
  • Secure Attribute
  • instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection
  • HttpOnly Attribute
  • instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object
  • Domain and Path Attributes
  • instructs web browsers to only send the cookie to the specified domain and all subdomains
  • “Domain” cookie attribute
  • “Path” cookie attribute
  • instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application
  • vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com
  • Expire and Max-Age Attributes
  • “Max-Age”
  • “Expires” attributes
  • it will be considered a
  • persistent cookie
  • and will be stored on disk by the web browser based until the expiration time
  • use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
  • Session ID Life Cycle
kuni katsuya

MySQL :: Enforcing Foreign Keys Programmatically in MySQL - 0 views

  • programmatically enforce foreign keys on storage engines which do not natively support them
  • done by the use of triggers
  • Enforcing Foreign Keys Programmatically in MySQL
  •  
    "UPDATE myisam_parent SET mparent_id=4 WHERE mparent_id=3; "
kuni katsuya

Class Loading in AS7 - JBoss AS 7.1 - Project Documentation Editor - 0 views

  • JBoss Deployment Structure File
  • jboss-deployment-structure.xml
  • control class loading in a fine grained manner
  • ...3 more annotations...
  • Prevent automatic dependencies from being added Add additional dependencies Define additional modules  Change an EAR deployments isolated class loading behaviour Add additional resource roots to a module
  • Class Loading in AS7
  • Automatic dependencies can be excluded through the use of jboss-deployment-structure.xml
« First ‹ Previous 41 - 58 of 58
Showing 20 items per page