Skip to main content

Home/ SoftwareEngineering/ Group items tagged usage

Rss Feed Group items tagged

kuni katsuya

Welcome to PMD - 0 views

kuni katsuya

Chapter 2. Usage Scenarios - 0 views

  • Client Options
  • client there are two main choices
  • standard Flex RemoteObject API
  • ...16 more annotations...
  • GraniteDS does not support the standard Consumer and Producer Flex messaging API
  • its own client implementations of these classes org.granite.gravity.Consumer and org.granite.gravity.Producer that provide very similar functionality
  • Tide remoting API with the GraniteDS/Tide server framework integration
  • most advanced features and greatly simplifies asynchronous handling and client data management
  • preferred for new projects
  • Server Options
  • two options
  • GraniteDS service factory
  • RemoteObject API,
  • GraniteDS support for externalization of lazily loaded JPA entities/collections, and support for scalable messaging though Gravity
  • GraniteDS/Tide service factory
  • Tide API
  • full feature set of Tide data management and further integration with data push through Gravity
  • complete support for Spring and Seam security or integration with CDI events
  • Tide/CDI/JPA2/Java EE 6 on JBoss 6/7 or GlassFish 3
  • If you are on a Java EE 6 compliant application server, it is definitely the best option
kuni katsuya

TH01-EP03-US004 - Property Mgmt, Edit Location & Directions, Content Mgmt - Projects - ... - 0 views

  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • ...18 more annotations...
  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • As a user
    • kuni katsuya
       
      with what granted roles? from which organization?
  • ability to see
    • kuni katsuya
       
      permissions required: retrieve these resource types
  • Location Type
  • Description
  • Airports
  • belonging to other organizations
    • kuni katsuya
       
      content (license) owned by organization different than user's
  • clone this information
    • kuni katsuya
       
      clone = retrieve, then create ie. required permissions: {retrieve,create:}
  • have the rights
    • kuni katsuya
       
      generally speaking, there can be a few independent but overlapping mechanism that will control who is allowed to do what with content: 1. any subject's access to the content itself can be controlled via authorization rules (ie. required vs granted permissions) enforced via system-wide resource-based access control 2. content licensors (~content owners) can restrict the usage of their content by: * whom - ie. content licensee (legally/commercially represented by an organization) * how - eg. reuse as unmodified, create derivatives, composite, redistribute, etc * where - ie. distribution channels their content can be used (eg. only on hotel's vbrochure site, but not in any ids/gds channels) * when - temporal restrictions may limit scope of content license grant by: start, end, duration, season, etc 3. content licensees can further filter or funnel content available to them (resulting from a combination of license granted to them and access control) based on their own criteria (eg. generate a templated hotel presentation only if: at least 1 textual description, 5 photos and 1 video for a hotel is available with a license to combine them (composite content)
  • see how other organizations describe the property
    • kuni katsuya
       
      permission required: retrieve hotel descriptive content(?) owned by independent organization
  • Property Mgmt
  • which textual information
  • displayed
    • kuni katsuya
       
      displayed where? on specific channels?
  • ECM will ask user to confirm that the user has rights to use that content
    • kuni katsuya
       
      if ecm/vfml is to manage content licensing as a third party between organizations (content licensors & licensees) shouldn't ecm *know* if the user('s organization) has rights to use the content in question? is this question posed to the user (with required explicit acknowledgement) purely to absolve vfml from liability issues that may result from licensing disagreements?
  • property’s
    • kuni katsuya
       
      this being the user's (organization's) 'version'or 'view'of the hotel, since this user normally wouldn't/shouldn't be granted permissions to replace content for a hotel on a different organization's 'view'or 'version' of the same hotel
  • to see the user’s original content
    • kuni katsuya
       
      this implies that *at least* one version of such (temporarily) replaceable content needs to be managed/maintaned to allow reverting what if, deliberately, ignorantly or maliciously, a user replaces the same piece of--textual or any type, really--content for this hotel n times? will all n versions be required to be managed as an undo history? the user's ''original content'' might have been version 1, but equally might have been 1 mean: - previous version of the content, regardless of which user - initial version of that content attached to the hotel regardless of which user created/updated it and ignoring which organization owns it?, or, -
kuni katsuya

Java Persistence/ManyToMany - Wikibooks, open books for an open world - 0 views

  • Bi-directional Many to Many
  • object model can choose if it will be mapped in both directions
  • in which direction it will be mapped
  • ...9 more annotations...
  • one direction must be defined as the owner and the other must use the mappedBy attribute to define its mapping
  • you will end up getting duplicate rows
  • If the mappedBy is not used, then the persistence provider will assume there are two independent relationships
  • As with all bi-directional relationships it is your object model's and application's responsibility to maintain the relationship in both direction
  • Mapping a Join Table with Additional Columns
  • solution is to create a class that models the join table
  • requires a composite primary key
  • To make your life simpler, I would recommend adding a generated Id attribute to the association class
  • Another usage is if you have a Map relationship between two objects, with a third unrelated object or data representing the Map key
    • kuni katsuya
       
      eg. map key = AuthorizationContext, map value = {Subject,Role}
kuni katsuya

Java Persistence/Transactions - Wikibooks, open books for an open world - 0 views

  • JTA transactions are
  • implicitly defined through SessionBean usage/methods. In a SessionBean normally each SessionBean method invocation defines a JTA transaction.
  • JTA Transactions
  • ...10 more annotations...
  • In JEE managed mode, such as an EntityManager injected into a SessionBean, the EntityManager reference, represents a new persistence context for each transaction. This means objects read in one transaction become detached after the end of the transaction, and should no longer be used, or need to be merged into the next transaction. In managed mode, you never create or close an EntityManager.
  • Transactions
  • operations that are committed or rolled back as a single unit
  • JPA provides two mechanisms for transactions
  • JTA (Java Transaction API
  • EntityTransaction
  • all changes made to all persistent objects in the persistence context are part of the transaction.
  • Nested Transactions
  • do not support nested transactions
  • JPA and JTA
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

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

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
1 - 13 of 13
Showing 20 items per page