Skip to main content

Home/ Groups/ SoftwareEngineering
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

MySQL Error Number 1005 Can't create table '.mydb#sql-328_45.frm' (errno: 150) | VerySi... - 0 views

  • MySQL Error Number 1005 Can’t create table
  • (errno: 150)
  • SHOW ENGINE INNODB STATUS
  • ...12 more annotations...
  • Known Causes:
  • First Steps:
  • dreaded errno 150:
  • The two key fields type and/or size is not an exact match
  • One of the key field that you are trying to reference does not have an index and/or is not a primary key
  • One or both of your tables is a MyISAM table
  • You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL
  • Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns
  • You have a default value (ie default=0) on your foreign key column
  • You have a syntax error in your ALTER statement or you have mistyped one of the field names in the relationship
  • The name of your foreign key exceeds the
  • max length of 64 chars
    • kuni katsuya
       
      64 char max? seriously??? in this century?!
kuni katsuya

Authorization | Apache Shiro - 0 views

  • PermissionResolver
  • use the PermissionResolver to convert the string into a Permission instance, and perform the check that way
  • All Shiro Realm implementations default to an internal
  • ...26 more annotations...
  • WildcardPermissionResolver
  • which assumes Shiro's
  • WildcardPermission
  • String format.
  • Authorization Sequence
  • what happens inside Shiro whenever an authorization call is made.
  • invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission*
  • securityManager implements the org.apache.shiro.authz.Authorizer interface
  • delegates to the application's SecurityManager by calling the securityManager's nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants
  • relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer's respective hasRole*, checkRole*, isPermitted*, or checkPermission* method
  • Realm's own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called
  • Authorization Sequence
  • Authorization Sequence
  • Authorization Sequence
  • Implicit Roles:
    • kuni katsuya
       
      BAD! do not use. prefer explicit (see below)
  • implies a set of behaviors (i.e. permissions) based on a role name only
  • Excplict Roles
  • named collection of actual permission statements
  • your realm is what will tell Shiro whether or not roles or permissions exist
  • Each Realm interaction functions as follows:
  • key difference with a RolePermissionResolver however is that the input String is a role name, and not a permission string.
  • Configuring a global RolePermissionResolver
  • RolePermissionResolver has the ability to represent Permission instances needed by a Realm to perform permission checks.
  • translate a role name into a concrete set of Permission instances
  • globalRolePermissionResolver = com.foo.bar.authz.MyPermissionResolver ... securityManager.authorizer.rolePermissionResolver = $globalRolePermissionResolver
  • shiro.ini
kuni katsuya

AllPermission (Apache Shiro 1.2.1 API) - 0 views

  • AllPermission
  • always implies any other permission
    • kuni katsuya
       
      equivalent to *:*, ie. all actions on all resource types
  • implies method
  • ...2 more annotations...
  • always returns true
  • have the ability to do anything
kuni katsuya

WildcardPermission (Apache Shiro 1.2.1 API) - 0 views

  • first token is the
  • domain
  • second token is the
  • ...7 more annotations...
  • action b
  • eing performed
  • boolean implies(Permission p)
  • Returns true if this current instance
  • implies all the functionality and/or resource access described by the specified Permission argument
  • false otherwise
  • current instance must be exactly equal to or a superset of the functionalty and/or resource access described by the given Permission argument
  •  
    "first token is the"
kuni katsuya

RolePermissionResolver (Apache Shiro 1.2.1 API) - 0 views

  • RolePermissionResolver
  • resolves a String value and converts it into a Collection of Permission instances
  •  Collection<Permission> resolvePermissionsInRole(String roleString)
  • ...2 more annotations...
  • role name to resolve
  • Collection of Permissions
kuni katsuya

Architecture | Apache Shiro - 0 views

  • Realm is essentially a security-specific DAO
  • 3 primary concepts:
  • Subject
  • ...51 more annotations...
  • SecurityManager
  • Realms
  • High-Level Overview
  • Subject
  • essentially a security specific 'view' of the the currently executing user
  • Subject
  • instances are all bound to (and require) a
  • SecurityManager
  • When you interact with a Subject, those interactions translate to subject-specific interactions with the SecurityManager
  • SecurityManager
  • 'umbrella’ object that coordinates its internal security components that together form an object graph
  • Realms
  • ‘connector’ between Shiro and your
  • application’s security data
  • Shiro looks up many of these things from one or more Realms configured for an application
  • Subject
  • SecurityManager
  • Authenticator
  • Authorizer
  • component responsible determining users' access control in the application
  • if a user is allowed to do something or not
  • SessionManager
  • knows how to create and manage user
  • Session
  • lifecycles
  • Shiro has the ability to natively manage user Sessions in any environment, even if there is no Web/Servlet or EJB container available
  • Shiro will use
  • an existing session mechanism
  • if available, (e.g. Servlet Container)
  • if there isn't one, such as in a standalone application or non-web environment, it will use its
  • built-in enterprise session management
  • SessionDAO
  • exists to allow any datasource to be used to
  • persist sessions
  • SessionDAO
  • performs Session persistence (CRUD) operations on behalf of the SessionManager
  • allows any data store to be plugged in to the Session Management infrastructure
  • CacheManager
  • creates and manages Cache instance lifecycles used by other Shiro components
  • improve performance while using these data source
  • Cryptography
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • Realms
  • Realms
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
kuni katsuya

Testing | Apache Shiro - 0 views

  • Testing with Apache Shiro
  • how to enable Shiro in unit tests.
  • Subject
  • ...14 more annotations...
  • is security-specific view of the
  • 'currently executing' user
  • and that Subject instances are always bound to a thread to ensure we know who is executing logic at any time during the thread's execution
  • Subject instance must be created
  • Subject instance must be bound to the currently executing thread
  • Subject must be unbound to ensure that the thread remains 'clean' in any thread-pooled environment
  • Shiro has architectural components that perform this bind/unbind logic automatically
  • root Shiro Filter performs this logic when filtering a request
  • after creating a Subject instance, it must be bound to thread
  • Test Setup
  • 'setup' and 'teardown'
  • can be used in both unit testing and integration testing
  • AbstractShiroTest
  • abstract class AbstractShiroTest
kuni katsuya

Java EE Revisits Design Patterns: Asynchronous - Java Code Geeks - 0 views

  • Java EE Revisits Design Patterns: Asynchronous
  • @Asynchronous
  • tell the JavaEE container to run the called method in a separate thread asynchronously
  • ...5 more annotations...
  • @Asynchronous
  • @Asynchronous
  • Future<>
  • simple to use
  • as a return type and to receive a result asynchronously
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

Shiro User - Shiro in CDI/JPA2/JSF2 project - 1 views

  • CDI, JPA2 and JSF2
  • Apache Shiro
  • JpaRealm
  • ...10 more annotations...
  • Entity Beans in combination with an EntityManager
  • use CDI to inject the EntityManager into my JpaRealm
  • JpaRealm is not container managed but is instantiated by Shiro
  • delegate your JpaRealm into @Stateless EJB, which can @Inject EntityManager
  • JpaRealm
  • @PersistenceContext   private EntityManager entityManager;
  • EnvironmentLoaderListener
  • found the cause
  • Instead of configuring the ShiroFilter in my web.xml I had the IniShiroFilter configured. The IniShiroFilter creates a new SecurityManager from the ini file. This new SecurityManager didn't know about the realm I've added in my EnvironmentLoader, so it didn't have any realms.
  • I replaced it with the ShiroFilter in my web.xml and all seems to be working now with my CdiEnvironmentLoaderListener.
kuni katsuya

How to get EntityManager in a Apache Shiro Realm | OpenShift by Red Hat - 0 views

kuni katsuya

java - Getting confused with Apache Shiro and Custom Authorizing Realms - Stack Overflow - 0 views

  • getRealms()
  • RealmSecurityManager
  • authorization is effectively disabled due to the default doGetAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) implementation returning null
kuni katsuya

Forgot Password Cheat Sheet - OWASP - 0 views

  • Forgot Password Cheat Sheet
  • no industry standard for implementing a Forgot Password feature
  • Step 1) Gather Identity Data or Security Questions
  • ...12 more annotations...
  • asks the user for multiple pieces of hard data that should have been
  • previously collected
  • send the password reset information to some
  • out-of-band side-channel
  • such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3.
  • Step 2) Verify Security Questions
  • application verifies that each piece of data is correct for the given username
  • If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as “Sorry, invalid data”. If all submitted data is correct, Step 2 should display at least two of the user’s pre-established personal security questions, along with input fields for the answers.
  • Avoid sending the username as a parameter
  • Do not provide a drop-down list
  • server-side session
  • user's email account may have already been compromised
kuni katsuya

Authentication Cheat Sheet - OWASP - 0 views

  • Authentication Cheat Sheet
  • Sessions should be
  • unique per user
  • ...26 more annotations...
  • computationally very difficult to predict
  • "strong" password policy
  • Secure Password Recovery Mechanism
  • Require re-authentication for Sensitive Features
  • Authentication and Error Messages
  • can be used for the purposes of user ID and password enumeration
  • Incorrectly implemented error messages
  • generic manner
  • respond with a generic error message regardless if the user ID or password was incorrect
  • give no indication to the status of an existing account
  • Authentication responses
  • Invalid user ID or password"
  • does not indicate if the user ID or password is the incorrect parameter
  • Transmit Passwords Only Over TLS
  • login page
  • all subsequent authenticated pages
  • must be exclusively accessed over TLS
  • unencrypted session ID
  • credentials
  • Implement Account Lockout
  • lock out an account if more than a preset number of unsuccessful login attempts are made
  • can produce a result that locks out entire blocks of application users accounts
    • kuni katsuya
       
      somewhat of a denial-of-service attack, since legitimate users can no longer access their accounts/services
  • sensible strategy
  • is to lockout accounts for a number of hours
  • Password lockout mechanisms have a logical weakness
  • Session Management General Guidelines
kuni katsuya

SQL Injection Prevention Cheat Sheet - OWASP - 0 views

  • SQL Injection Prevention Cheat Sheet
  • it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.
  • create dynamic database queries that include user supplied input
  • ...19 more annotations...
  • a) stop writing dynamic queries
  • b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query
  • Primary Defenses:
  • Option #1: Use of Prepared Statements (Parameterized Queries)
  • Option #3: Escaping all User Supplied Input
  • Additional Defenses:
  • Enforce: Least Privilege
    • kuni katsuya
       
      least privilege should be *required*, included as a primary defense
  • Perform: White List Input Validation
  • Primary Defenses
  • Defense Option 1: Prepared Statements (Parameterized Queries)
  • attacker is not able to
  • change the intent
  • of a query, even if SQL commands are inserted by an attacker
  • allows the database to
  • distinguish
  • between
  • data,
  • code a
  • Defense Option 3: Escaping All User Supplied Input
« First ‹ Previous 481 - 500 of 1272 Next › Last »
Showing 20 items per page