Read the complete post at LiveCycle blog
Read the complete post at LiveCycle blog
To know more, read Sudhanshu Singh's blog post on the LiveCycle blog.
Recently I worked on a customer issue where in they were seeing an error when the user logged into their AIR client on MAC and was unable to access the application.
The error seen was :
LC_AuthenticateUser Error: com.adobe.idp.um.api.UMException| [com.adobe.idp.um.api.impl.AuthenticationManagerImpl] errorCode:16386 errorCodeHEX:0×4002 message:user_identifier:Z027223 domain:DefaultDomcom.adobe.idp.common.errors.exception.IDPException| [com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean] errorCode:13316 errorCodeHEX:0×3404 message:user_identifier: Z027223 domain:DefaultDom;
Read the complete post at Adobe LiveCycle Blog.
You must have the Application Administrator role assigned to your LiveCycle ES2 user account in order to develop applications. In this role, you can assign limited access to the application development environment for users who have other roles assigned. You can permit other users to have the following type of access:
- Read: The user can view the application.
- Delegate: Although the user is not the Application Administrator, that user can extend read/write permissions to another user.
- Write: The user can modify the application and save the changes.
Essentially one can classify user permissions under the following two categories:
- Role Based Permissions
- Resource Level Permissions
Role Based Permissions typically would cover the roles that the user has been assigned via the Role Assignment interface and this supersedes the “Resource Level Permission ” which are assigned via the Manage Access interface as described in the following link.
In order to achieve the above scenario one would need to ensure that the user has not been assigned any such permissions which would otherwise allow the user to perform the Read/Delegate/Write operations on an application.
Read the complete post at https://blogs.adobe.com/livecycle/2012/07/managing-user-access.html.
For IBM WebSphere, see here.
LiveCycle ES2′s Configuration Manager (LCM) provides you two options for configuring JDBC data sources in WebLogic:
1) Package it inside the EAR files (more secure)
2) Create it in the WebLogic Admin Console
Choice #2 provides a lot more flexibility when it comes to configuring the data sources for database failover. Runtime configuration changes such as increasing the pool size can be done without having to un-deploy and re-deploy EAR files.
To ensure that the connections in the connection pool are valid, the following additional configuration changes are necessary. This is based on an actual customer deployment against an active-passive SQL Server database cluster. You can make changes as necessary to fit your IT environment.
1) In the ‘Connection Pool‘ tab for the JDBC data source, in the ‘Advanced‘ section, ensure that the checkbox for ‘Test Connections on Reserve‘ is checked
2) Set ‘Test Frequency‘ to 10 seconds
3) Set ‘Test Table Name‘ to “DUAL” or “EDCJOBENTITY”
4) Set ‘Seconds to Trust an Idle Pool Connection‘ to 5 seconds
5) Set ‘Init SQL‘ to “SQL SELECT * FROM DUAL” or “SQL SELECT COUNT(*) FROM EDCJOBENTITY”
6) Set ‘Connection Creation Retry Frequency‘ to 12 seconds
7) Set ‘Login Delay‘ to 0 seconds
8) Set ‘Inactive Connection Timeout‘ to 0 seconds
9) Set ‘Connection Reserve Timeout‘ to 10 seconds
Original article at http://blogs.adobe.com/livecycle/2011/04/configuring-livecycle-jdbc-data-sources-in-weblogic-for-db-failover.html.
Session re-writing is the practice of adding the session identifier to the HTTP request URL instead of passing the session identifier as a session cookie. Session re-writing is usually used when cookies have been disabled on the client. It is an easy way to let clients that do not allow or support cookies maintain session state with the server but it poses some security risks. The session identifier is passed in the URL which means that it is not encrypted even if the request is made over SSL/HTTPS. Because of the security risks associated with session re-writing, the Open Web Application Security Project (OWASP) recommends that session re-writing only be used for low-value sites. In this article, I will show you how to disable session re-writing in BlazeDS and LCDS to help secure your application.
In BlazeDS and LCDS, the session identifier is typically either the JSessionId (for servlet based endpoints in BlazeDS or LCDS) or AMFSessionId (for NIO HTTP based endpoints in LCDS).
Note that the RTMP protocol doesn’t use HTTP, so the issue of session re-writing doesn’t apply to RTMP endpoints.
When the BlazeDS or LCDS server receives a request with no session identifier (either a session cookie or session id URL parameter) a couple things happen. A new session is created. A Set-Cookie header with the session id is added to the response. Also, an AppendToGatewayURL header with the session id is added to the AMF or AMFX response message.
In this article, I will point out the main areas where data and disk space use can happen, and how to clean up.
Read the complete post here.