主题 : 通过code获取accessToken信息，报400错误
级别: 新手上路
UID: 489954
可可豆: 112 CB
威望: 70 点
在线时间: 51(时)
发自: Web Page
来源于&&分类
通过code获取accessToken信息，报400错误&&&
//通过code获取accessToken信息，回调页面能正常跳转&- (void)accessToken:(NSString *)code&{&    AFHTTPRequestOperationManager *mgr = [AFHTTPRequestOperationManager manager];&    mgr.responseSerializer = [AFHTTPResponseSerializer serializer];& &    NSMutableDictionary *params = [NSMutableDictionary dictionary];&    params[@&client_id&] = @&&;&    params[@&client_secret&] = @&1fddd21ffbef&;&    params[@&grant_type&] = @&authorization_code&;&    params[@&code&] =&    params[@&redirect_uri&] = @&&;& &    [mgr POST:@&/oauth2/access_token& parameters:params&      success:^(AFHTTPRequestOperation *operation, id responseObject) {& &          NSLog(@&%@&,responseObject);& &      } failure:^(AFHTTPRequestOperation *operation, NSError *error) {&          NSLog(@&%@&,error);&      }];&｝&&报错信息：&&Error Domain=com.alamofire.error.serialization.response Code=-1011 &Request failed: bad request (400)& UserInfo=0x78fe4b00 {com.alamofire.serialization.response.error.response=&NSHTTPURLResponse: 0x7a66d3e0& { URL:
} { status code: 400, headers {&    &Cache-Control& = &no-cache&;&    Date = &Sun, 19 Jul :01 GMT&;&    Expires = &Thu, 01 Jan :00 GMT&;&    Pragma = &No-cache&;&    Server = &nginx/1.6.1&;&    &api-server-ip& = &10.75.25.86&;&} }, NSErrorFailingURLKey=/oauth2/access_token, NSLocalizedDescription=Request failed: bad request (400), com.alamofire.serialization.response.error.data=&7bf96e f2 2cf725f 636f1 2f 6f22f61 f746f 6b656e22 2cf725f a222f6f f3 5f746f6b 656e222c f725f64 e223a c4 686f469 6f6e53a 66 d&}
级别: 新手上路
可可豆: 1 CB
威望: 1 点
在线时间: 4(时)
发自: Web Page
回 楼主(Benjamin_BBK) 的帖子
楼主问题解决了嘛？我跟你遇到的问题一模一样，搜了好多也没有找到解决办法
级别: 新手上路
UID: 489954
可可豆: 112 CB
威望: 70 点
在线时间: 51(时)
发自: Web Page
回 1楼(peicj) 的帖子
已经解决了，我那时候是网址拼接的时候出现错误，所以一直报错
级别: 新手上路
可可豆: 1 CB
威望: 1 点
在线时间: 9(时)
发自: Web Page
回 2楼(Benjamin_BBK) 的帖子
那个网址拼接,怎么改的??
级别: 新手上路
可可豆: 1 CB
威望: 1 点
在线时间: 4(时)
发自: Web Page
楼主怎么解决的,&&&&我也是这个报错, 一模一样的,&& 请问怎么解决的
级别: 新手上路
可可豆: 2 CB
威望: 2 点
在线时间: 80(时)
发自: Web Page
回 2楼(Benjamin_BBK) 的帖子
怎么解决的&
级别: 侠客
UID: 546718
可可豆: 575 CB
威望: 352 点
在线时间: 201(时)
发自: Web Page
怎么解决的！！！！！！！！
级别: 新手上路
可可豆: 1 CB
威望: 1 点
在线时间: 0(时)
发自: Web Page
跟楼主错误一模一样 怎么改呢
级别: 新手上路
可可豆: 22 CB
威望: 22 点
在线时间: 1(时)
发自: Web Page
回 楼主(Benjamin_BBK) 的帖子
楼主,你这个问题怎么解决的,天,我搞了2天,没解决
关注本帖(如果有新回复会站内信通知您)
苹果公司现任CEO是谁？2字 正确答案:库克
发帖、回帖都会得到可观的积分奖励。
按"Ctrl+Enter"直接提交
关注CocoaChina
关注微信 每日推荐
扫一扫 浏览移动版23.1 About Remote Intradoc Client (RIDC)
Remote Intradoc Client (RIDC) is a thin communication API for talking to the Content Server. It's main functionality is to provide the ability to remotely execute Content Server services. In addition, RIDC handles things like connection pooling, security, and protocol specifics.
Remote Intradoc Client (RIDC) has these features:
Supports Intradoc socket-based communication and the HTTP and JAX-WS protocols.
Supports Secure Socket Layer (SSL) communication with Content Server.
Provides client configuration including setting the socket time outs, connection pool size, and so on.
RIDC objects follow the standard Java Collection paradigms.
Remote Intradoc Client (RIDC) version 11.1.1.6.0 supports the idc, idcs, http, https, and jax-ws protocols.
Intradoc: The Intradoc protocol communicates to the Content Server over the over the Intradoc socket port (typically 4444). This protocol requires a trusted connection between the client and Content Server and will not perform any password validation. Clients that use this protocol are expected to perform any required authentication themselves before making RIDC calls. The Intradoc communication can also be configured to run over SSL.
HTTP: Using the Apache HttpClient package, RIDC communicates with the web server attached to the Content Server. Unlike Intradoc, this protocol requires authentication credentials for each request. HttpClient version 3 is the default. However, version 4 of the httpClient library may also be used. See
for details. Refer to the Jakarta Commons HttpClient documentation on the HttpClient Home page of the Apache HttpClient web site for additional information.
JAX-WS: The JAX-WS protocol is only supported in Oracle WebCenter Content 11g with a properly configured Content Server instance and the RIDC client installed. JAX-WS is not supported outside this environment.
For more information about JAX-WS, see
on the Oracle Technology Network (OTN). Also see the Java API for XML Web Services (JAX-WS) documentation on the Java Community Process web site:
The following table shows the URL formats that are supported.
The following table summarizes the environment RIDC needs to support each connection type.
23.1.1 Using HttpClient Library Version 4
Using the Apache HttpClient package, RIDC communicates with the web server attached to the Content Server. Unlike Intradoc, this protocol requires authentication credentials for each request. Remote Intradoc Client (RIDC) version 11.1.1.6.0 uses HttpClient version 3 as the default. However, version 4 of the HttpClient library may also be used.
Refer to the Jakarta Commons HttpClient documentation on the HttpClient Home page of the Apache HttpClient web site for additional information.
To request HttpClient version 4 in Java code:
IdcClient idcClient = manager.createClient("http://localhost/idc/idcplg");
idcClient.getConfig ().setProperty ("http.library", "apache4");
If you are creating a new RIDC application using the JDeveloper extension, you can add to your connection, in the Configuration Parameters section, the parameter "http.library" with a value of "apache4". See
for more information on the RIDC JDeveloper extension
If you are in a Site Studio for External Applications (SSXA) application in JDeveloper, because there is no UI, you need to create your connection and save it without testing the connection first. Then open the connections.xml file in the Connections & Descriptors & ADF META-INF node. Add the following StringRefAddr section (shown in ) to the connections.xml file and save the file.
Example 23-1 Connection Example in connections.xml
&Reference name="sample"
className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns=""&
&Factory className=
"oracle.stellent.ridc.convenience.adf.mbeans.IdcConnectionFactory"/&
&RefAddresses&
&StringRefAddr addrType="oracle.stellent.idc.connectionUrl"&
&Contents&idc://localhost:4444&/Contents&
&/StringRefAddr&
&StringRefAddr addrType="oracle.stellent.idc.idcServerURL"&
&Contents&http://localhost/cs/idcplg&/Contents&
&/StringRefAddr&
&StringRefAddr addrType="oracle.stellent.idc.http.library"&
&Contents&apache4&/Contents&
&/StringRefAddr&
&/RefAddresses&
&/Reference&
Note that the connection types for SSXA and RIDC are similar:
When you are using SSXA connections in JDeveloper, the addrType value in the connections.xml file is oracle.stellent.idc.http.library.
When you are using RIDC connections in JDeveloper the addrType value in the connections.xml file is oracle.stellent.ridc.http.library.
23.2 Initializing Connections
This section provides sample code to initialize an Intradoc connection, an HTTP connection, and code that initializes a JAX-WS client.
The code in
initializes an Intradoc connection.
Example 23-2 Intradoc Connection Initialization
// create the manager
IdcClientManager manager = new IdcClientManager();
// build a client that will communicate using the intradoc protocol
IdcClient idcClient = manager.createClient("idc://localhost:4444");
The code in
initializes an HTTP connection. The only difference from an Intradoc connection is the URL.
Example 23-3 HTTP Connection Initialization
// create the manager
IdcClientManager manager = new IdcClientManager();
// build a client that will communicate using the HTTP protocol
IdcClient idcClient = manager.createClient("http://localhost:16200/idc/idcplg");
The code in
initializes a JAX-WS client. Note that the URL includes the idcnativews web context root. This web context root (by default) is used by two web services exposed by the Content Server: the login service and the request service.
Example 23-4 JAX-WS Client Initialization
// create the manager
IdcClientManager manager = new IdcClientManager();
// build a client that will communicate using the JAXWS protocol
IdcClient idcClient = manager.createClient
("http://wlsserver:16200/idcnativews");
23.3 Configuring Clients
Configuration of the clients can be done after they are created. Configuration parameters include setting the socket timeouts, connection pool size, etc. The configuration is spec if you cast the IdcClient object to the specific type, then you can retrieve the protocol configuration object for that type.
The code in
sets the socket time-out and wait time for Intradoc connections.
Example 23-5 Client Configuration for Intradoc Connections
// build a client as cast to specific type
IntradocClient idcClient =
(IntradocClient)manager.createClient("http://localhost/idc/idcplg");
// get the config object and set properties
idcClient.getConfig().setSocketTimeout(30000);
// 30 seconds
idcClient.getConfig().setConnectionSize(20);
// 20 connections
Remote Intradoc Client (RIDC) allows Secure Socket Layer (SSL) communication with Content Server using the Intradoc communication protocol. The typical port used is 4444. For more information about configuring SSL and enabling ports, see the .
For SSL communication, you must install and enable the SecurityProviders component in the Content Server instance that you want to access. You must configure Content Server for SSL communication with a new incoming provider, and specify the truststore or keystore information. You must have a valid keystore or trust manager with signed, trusted certificates on both the client and Content Server.
Oracle does not provide signed certificates. For most implementations, you will want a certificate signed by a universally recognized Certificate Authority.
To configure SSL communication with Content Server, you need to do these tasks:
Install and enable the SecurityProviders component. The SecurityProviders component must be installed and enabled in the Content Server instance that you want to access with SSL communication.
This component is installed and enabled by default in Oracle WebCenter Content Server 11gR1.
Configure an incoming provider for SSL communication.
For more information about configuring SSL, see the .
Create self-signed key pairs and certificates.
The code in
uses the IDC protocol over a Secure Socket (SSL).
Example 23-6 IDC Protocol over SSL
// build a secure IDC client as cast to specific type
IntradocClient idcClient = (IntradocClient)
manager.createClient("idcs://localhost:4443");
// set the SSL socket options
config.setKeystoreFile("ketstore/client_keystore");
//location of keystore file
config.setKeystorePassword ("password");
// keystore password
config.setKeystoreAlias("SecureClient");
//keystore alias
config.setKeystoreAliasPassword("password");
//password for keystore alias
There are several JAX-WS specific configurations that can be done after you have created the client. However, in most cases, you should use the default settings.
This code builds a client as a cast for a JAX-WS type:
JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient
("http://wlsserver:7044/idcnativews");
JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();
You can set the instance name of the Content Server that you would like to connect to. This is set to "/cs/" by default which is the default webcontext for UCM installation. If the server webcontext is different than the default, then you may set it as:
// set the property
jaxwsConfig.setServerInstanceName("/mywebcontext/");
Setting the JPS configuration file location. A JPS configuration file is required for most policies such SAML and/or Message Token.
jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");
Setting the security policy:
jaxwsConfig.setClientSecurityPolicy("policy:oracle/wss11_username_token_with_message_protection_client_policy");
Changing the Login Port WSDL URL
RIDC uses the default values for the installed webservices. If for some reason, the webservices have been modified and does not conform to the default URI/URLs, you may need to modify the default values.
Changing the login port WSDL URL:
jaxwsConfig.setLoginServiceWSDLUrl
(new URL("http://server:7044/webservices/loginPort?WSDL"));
Change the request service URL:
jaxwsConfig.setRequestServiceWSDLUrl
(new URL("http://server:7044/anotherservice/myrequestport?WSDL"));
The default streaming chuck size is 8192. This example changes the chunk size:
jaxwsConfig.setStreamingChunkSize(8190);
To determine service side policy set for UCM: from the Admin Console select Deployments & Oracle UCM Native Web Services & IdcWebLoginService & Configuration & WS-Policy & IdcWebLoginPort & OWSM.
To determine GPA policy for a ws-client that will be leveraged by RIDC over JAX-WS should no explicit LPA be set: initialize the WebLogic Scripting Tool (WLST) and use the WebLogic Server Administration Scripting Shell.
The code in
provides an example.
Example 23-7 Determining GPA Policy with the WebLogic Scripting Tool
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline& connect('weblogic','welcome1','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.
wls:/base_domain/serverConfig& help('wsmManage')
Operations that provide support to manage the global policy attachments and
Oracle MDS repository.
help('abortRepositorySession')
Abort the current repository session,
discarding the changes made to repository.
help('attachPolicySet')
Attach a policy set to the specified resource scope.
help('attachPolicySetPolicy')
Attach a policy to a policy set using the policy's URI.
help('beginRepositorySession')
Begin a session to modify the repository.
help('clonePolicySet')
Clone a new policy set from an existing policy set.
help('commitRepositorySession')
Write the contents of the current session to the repository.
help('createPolicySet')
Create a new, empty policy set.
help('deletePolicySet')
Delete a specified policy set.
help('describeRepositorySession')
Describe the contents of the current repository session.
help('detachPolicySetPolicy')
Detach a policy from a policy set using the policy's URI.
help('displayPolicySet')
Display the configuration of a specified policy set.
help('enablePolicySet')
Enable or disable a policy set.
help('enablePolicySetPolicy')
Enable or disable a policy attachment
for a policy set using the policy's URI.
help('exportRepository')
Export a set of documents from the repository into a supported ZIP archive.
help('importRepository')
Import a set of documents from a supported ZIP archive into the repository.
help('listPolicySets')
Lists the policy sets in the repository.
help('migrateAttachments')
Migrates direct policy attachments to global policy attachments
if they are identical.
help('modifyPolicySet')
Specify an existing policy set for modification in the current session.
help('resetWSMPolicyRepository')
Clean the Oracle MDS repository and re-seed with the current set
of WSM policies.
help('setPolicySetDescription')
Specify a description for the policy set selected within a session.
help('upgradeWSMPolicyRepository')
Add newly introduced WSM policies to the Oracle MDS repository.
help('validatePolicySet')
Validate an existing policy set in the repository or in a session.
wls:/base_domain/serverConfig& listPolicySets()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)
Global Policy Sets in Repository:
base-domain-ws-client
wls:/base_domain/serverConfig& displayPolicySet('base-domain-ws-client')
Policy Set Details:
-------------------
Name: base-domain-ws-client
Type of Resources: Web Service Client
Scope of Resources: Domain("base_domain")
Description: Global policy attachments for Web Service Client resources.
Enabled: true
Policy Reference: security : oracle/wss10_saml_token_client_policy, enabled=true
The code in
sets the ws-client GPA policy.
Example 23-8 Add GPA for the Web Service Client
# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')
# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()
# confirm policy set created
listPolicySets()
# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')
# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()
# confirm policy set created
listPolicySets()
23.4 Authenticating Users
All calls to Remote Intradoc Client (RIDC) require some user identity for authentication. Optionally, this identity credential can be accompanied by other parameters such as a password as required by the protocol. The user identity is held in the IdcContext once created, it can be reused for all subsequent calls. To create a context, you pass in the user name and, optionally, some credentials.
Create a simple context with no password (for idc:// urls):
IdcContext userContext = new IdcContext("weblogic");
Create a context with a password:
IdcContext userPasswordContext = new IdcContext("weblogic", "welcome1");
For Intradoc URLs, no password is required in the credentials because the request is trusted between Content Server and the client.
For JAX-WS URLs, the requirement for credentials will be dependent on the service policy that the web service is configured to use by the server.
23.5 Using Services
To invoke a service use the IdcClient class method:
public ServiceResponse sendRequest (IdcContext userContext, DataBinder dataBinder) throws IdcClientException
For more information, see the .
The code in
executes a service request and gets back a data binder of the results.
Example 23-9 Executing a Service Request
// get the binder
DataBinder binder = idcClient.createBinder();
// populate the binder with the parameters
binder.putLocal ("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal ("QueryText", "");
binder.putLocal ("ResultCount", "20");
// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);
The ServiceResponse contains the response from Content Server. From the response, you can access the stream from the Content Server directly, or you can parse it into a DataBinder and query the results.
The code in
takes the ServiceResponse and gets the search results, printing out the title and author value.
Example 23-10 Get the Binder and Loop Over the Results
// get the binder
DataBinder binder = response.getResponseAsBinder ();
DataResultSet resultSet = binder.getResultSet ("SearchResults");
// loop over the results
for (DataObject dataObject : resultSet.getRows ()) {
System.out.println ("Title is: " + dataObject.get ("dDocTitle"));
System.out.println ("Author is: " + dataObject.get ("dDocAuthor"));
If you consume a stream, your code is responsible for closing the stream. The code in
provides an example of closing the stream.
Example 23-11 Closing the Steam
IdcContext user = new IdcContext ("weblogic", "welcome1");
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.getClient ("some url");
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);
InputStream stream =
stream = response.getResponseStream ();
int read = 0;
int total = 0;
byte[] buf = new byte[256];
while ((read = stream.read (buf)) != -1) {
} finally {
if (stream != null) {
stream.close ();
for information on connection pooling and closing via the stream.
23.6 Understanding Connection Pooling
The IdcClientConfig#getConnectionPool property determines how RIDC will handle pooling of connections. There are two options, simple and pool.
The simple option is the default. The simple option does not enforce a connection maximum and rather lets every connection proceed without blocking and does not enforce a connection maximum. In most cases this option should be used.
The pool option specifies the use of an internal pool that allows a configurable number of active connections at a time (configurable through the IdcClientConfig#getConnectionSize property), with the default active size set to 20.
Usually, when the RIDC library is used to communicate from an application that itself is in an application container (such as a web application), the inbound requests have already been throttled. Thus, the simple option is the correct choice to use. The only scenario to use the pool option is if you are creating a stand-alone server, and you are manufacturing a large number of concurrent calls to the Content Server which may cause the Content Server to become overwhelmed.
A different pool implementation can be registered via the IdcClientManager#getConnectionPoolManager()#registerPool() method, which maps a name to an implementation of the ConnectionPool interface. The name can then be used in the IdcClientConfig object to select that pool for a particular client.
23.7 Understanding Streams
Streams are sent to the Content Server through the TransferFile class. This class wraps the actual stream with metadata about the stream (length, name, and so on). For information about methods that allow check-ins of files and streams, see the .
The code in
performs a check-in to the Content Server:
Example 23-12 Content Server Check-In
// create request
DataBinder binder = idcClient.createBinder();
binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL");
// get the binder
binder.putLocal ("dDocTitle", "Test File");
binder.putLocal ("dDocName", "test-checkin-6");
binder.putLocal ("dDocType", "ADACCT");
binder.putLocal ("dSecurityGroup", "Public");
// add a file
binder.addFile ("primaryFile", new TransferFile ("test.doc"));
// check in the file
idcClient.sendRequest (userContext, binder);
Streams are received from the Content Server via the ServiceResponse object. For a summary of available methods, see the .
The response is not converted into a DataBinder unless specifically requested. If you just want the raw HDA data, you can get that directly, along with converting the response to a String or DataBinder.
The code in
executes a service, gets the response as a string, and parses it into a data binder.
Example 23-13 Parsing a String into a DataBinder
// create request
DataBinder binder = idcClient.createBinder ();
// execute the service
ServiceResponse response = idcClient.sendRequest (userContext, binder);
// get the response stream
InputStream stream = response.getResponseStream ();
// get the response as a string
String responseString = response.getResponseAsString ();
// parse into data binder
DataBinder dataBinder = response.getResponseAsBinder ();
23.8 Understanding Binders
Binders can be reused among multiple requests. A binder from one request can be sent in to another request. Note that if you reuse a binder from one call to the next you need to be very careful there is nothing leftover in the binder that could impact your next call. RIDC does not clean the binder after each call.
The code in
provides an example that pages the search results by reusing the same binder for multiple calls to Content Server.
Example 23-14 Reusing Binders
// create the user context
IdcContext idcContext = new IdcContext ("sysadmin", "idc");
// build the search request binder
DataBinder binder = idcClient.createBinder();
binder.putLocal("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal("QueryText", "");
binder.putLocal("ResultCount", "20");
// send the initial request
ServiceResponse response = idcClient.sendRequest (binder, idcContext);
DataBinder responseBinder = response.getResponseAsBinder();
// get the next page
binder.putLocal("StartRow", "21");
response = idcConnection.executeRequest(idcContext, binder);
responseBinder = response.getResponseAsBinder();
// get the next page
binder.putLocal("StartRow", "41");
response = idcConnection.executeRequest(binder, idcContext);
responseBinder = response.getResponseAsBinder();
23.9 Understanding Convenience Classes
There are some patterns of actions that many applications perform using RIDC. The convenience package supplies some of these for reuse. The classes in the convenience package space are consumers of the RIDC code and as such don't add any new functionality. They can be thought of as a new layer on top of RIDC.
23.9.1 Setting User Security
The Content Server has several security models that are controlled by settings on the Content Server. To resolve if a particular user has access to a document, three things are needed: The user's permission controls, the document's permission controls, and Content Server security environment settings.
It is assumed that the Application Program calling the UserSecurity module will fetch documents and the DOC_INFO metadata (in the document's binder, typically the result of a Search) as some superuser and cache this information. When the Application needs to know if a particular user has access to the document, a call is made to the Content Server as that user to fetch that user's permissions. Once the user's permission controls are known, then they can matched to the information in the document's metadata to resolve the access level for that user. (Access level is READ or READ/WRITE or READ/WRITE/DELETE). The need therefore is to reduce the number of calls to the Content Server (with a cache) and to provide a default implementation for matching the user's permissions information with the document's permission information. One further complication is that the Content Server controls which types of security are used in some server environment properties: UseAccounts=true and UseCollaboration=true or UseEntitySecurity=1. Additionally, a method allows testing to see if admin rights are assigned to a security type for that document.
The user security convenience is accessed through the IUserSecurityCache interface. There classes implement the optional Content Server security:
The UserSGAcctAclCache class should always be called. This class will check the Content Server for security configuration and internally adjust itself to match.
The UserSecurityGroupsCache class keeps a cache of user permissions and will match documents considering only Security Group information. Do not call this class directly. The UserSGAcctAclCache class will check the Content Server for security configuration and internally adjust itself to match.
The UserSGAccountsCache class adds a resolver to also consider Account information if the Content Server has the UseAccounts=true setting. Do not call this class directly. The UserSGAcctAclCache class will check the Content Server for security configuration and internally adjust itself to match.
For more information, see the .
The code in
provides an example of setting user security.
Example 23-15 Setting User Security
IdcClientManager m_clientManager = new IdcClientManager ();
IdcClient m_client = m_clientManager.createClient
("http://localhost/scs/idcplg");
//RIDC superuser context
IdcContext m_superuser = new IdcContext("sysadmin", "idc");
//This class will self-adjust (downwards) to match the security model
// on the content server
IUserSecurityCache m_userSecurityCache = new UserSGAcctAclCache
(m_client, 20, , m_superuser);
ITrace trace =
//Example test
testDocPermission () {
//If you don't want to do any logging, you can leave trace as null
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
trace = new Trace ();
DataBinder m_doc1 = getDataBinder ("TEST");
//Get the document information (typically in the first row of DOC_INFO)
DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0);
//Get the cache id for this user
//This makes a live call to content server to get the user ID for "Acme1"
//CacheId acme1 = m_userSecurityCache.getCacheIdForUser
(new IdcContext("Acme1", "idc"), trace);
IdcContext context = new IdcContext("Acme1", "idc");
CacheId acme1 = new CacheId (context.getUser (), context);
//Get the access level for this document by this user
int access = m_userSecurityCache.getAccessLevelForDocument
(acme1, docInfo, trace);
//Check if user has ACL admin permissions
boolean aclAdmin = m_userSecurityCache.isAdmin
(acme1, docInfo, IUserSecurityCache.AdminType.ACL, trace);
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
m_log.log (trace.formatTrace (), ILog.Level.TRACE);
//Example code to get a Document's DOC_INFO databinder
DataBinder getDataBinder (String dDocName) throws IdcClientException {
DataBinder dataBinder = m_client.createBinder ();
dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME");
dataBinder.putLocal ("dDocName", dDocName);
ServiceResponse response = m_client.sendRequest (m_superuser, dataBinder);
return response.getResponseAsBinder ();
//Example code to create a DataObject
DataObject dataObject = m_client.getDataFactory ().createDataObject ();
dataObject.put ("dSecurityGroup", "public");
dataObject.put ("dDocAccount", "Eng/Acme");
Internally, these fields from the document are examined during getAccessLevelForDocument():
For the AccessResolverSecurityGroups class: dSecurityGroup.
For the AccessResolverAccounts class: dDocAccount.
For the AccessResolverSecurityGroups class: xClbraUserList, xClbraAliasList, and xClbraRoleList.
The IAccessResolver classes determine if they should participate based on cached information from the Content Server, if they do participate, the access levels are ANDed together. You can use the hasAdmin() method to determine if there is admin access. For more information, see the .
23.9.2 Setting the ADF Connection Facade
Remote Intradoc Client (RIDC) version 11.1.1.6.0 includes the AdfConnectionFacade convenience class which provides a simple way to store connection details, obtain the idcClient object and create the user credential objects. It also provides a connection UI in the jdeveloper extension.
The code in
will fetch a facade for a connection named "example1" and performs a test to see if the connection can be made.
Example 23-16 Fetch Facade and Perform Test
AdfConnectionFacade facade = new AdfConnectionFacade ("example1");
boolean ok = facade.testConnection ("user").isSuccess()
AdfConnectionFacade.ResultTestConnection testResult =
facade.testConnection ("user");
if (!testResult.isSuccess ()) {
throw new IdcClientException (testResult.getMessage ());
You can add more user credentials in the Jdeveloper UI by following this naming pattern for the parameter names &Credentials Label&.&Credentials Type&.&Field Name&.
For example:
admin1.basic.name
admin1.basic.password
Using facade.getUserCredentials("admin1") will return populated BasicCredentials class.
public.nameonly.name
Using facade.getUserCredentials("public") will return populated UserNameOnlyCredentials class. Use value of &default& to get the internal default username
myuser.adf.name
Using facade.getUserCredentials("myuser") will return AdfUserCredentials class.
When the RIDC call is made the logged user is fetched with this code:
ADFContext.getCurrent ().getSecurityContext().getUserName()
These additional parameters are understood automatically by RIDC:
connectionSize
connectionWaitTime
connectionPool
socketTimeout
useSystemProxy
http.proxyHost
http.proxyPort
http.nonProxyHosts
http.proxyUserName
http.proxyPassword
http.library
sslKeystoreFile
sslKeystorePassword
sslAlgorithm
sslKeystoreAlias
sslKeystoreAliasPassword
sslTrustManagerFile
sslTrustManagerPassword
clientSecurityPolicy
jaxWsStack
streamingChunkSiz
23.10 Understanding RIDC Filters
Remote Intradoc Client (RIDC) version 11.1.1.4.0 and greater, permits your application code the ability to add a filter before the DataBinder is processed and sent to the Content Server. You can create a filter by extending one of the IdcFilterAdapter classes, and then register that filter to execute with the IdcFilterManager class. Filters are executed in the order specified when registered. You can also get and remove previously registered filters.
The code in
extends an adapter and overrides a method to perform an action.
Example 23-17 Calling RIDC Filter Before Service Request
public class IdcFilterAddComment extends BeforeServiceRequestFilter {
public void beforeServiceRequest
(IdcClient client, IdcContext context, DataBinder binder)
throws IdcClientException {
String existingComments = binder.getLocal("xComments");
if (existingComments != null) {
binder.putLocal("xComments", String.format
("%s %s", existingComments, "--DGT WAS HERE--"));
binder.putLocal("xComments", "--DGT WAS HERE--");
Remote Intradoc Client (RIDC) version 11.1.1.5.0 or later provides two more filter locations in the JAX-WS processing area. To use these filters, extend the BeforeJaxwsServiceFilter class.
The code in
extends the BeforeJaxwsServiceFilter class.
Example 23-18 Calling RIDC Filter Before JAX-WS Call
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerLogin () in authenticateUser ()
public void beforeJaxwsAuthenticateUser (IdcContext context, DataBinder binder,
Map&String, Object& requestContext) throws IdcClientException {
requestContext.put(oracle.wsm.security.util.SecurityConstants.
ClientConstants.WSM_SUBJECT_PRECEDENCE, &false&);
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerRequest () in performServiceRequest ()
public void beforeJaxwsServiceRequest (IdcContext context, DataBinder binder,
Map&String, Object& requestContext) throws IdcClientException {
//Override this class and implement your filter here
The code in
registers your filter class(es).
Example 23-19 Register Filer Classes
// If you are at the start of a pure RIDC application, you typically
// will create a ClientManager, for example:
IdcClientManager m_clientManager = new IdcClientManager();
// New method added to IdcClient to get the ClientManager
// if you do not have the ClientManager instance:
IdcClient client = myC
client.getClientManager();
// From the ClientManager, you can get the FilterManager:
IdcFilterManager fmanager = m_clientManager.getFilterManager();
// Then register your filter:
IIdcFilter addCommentFilter = new IdcFilterAddComment();
int slot = fmanager.registerFilter(100, addCommentFilter);
// Optionally, you can deregister. However, it might not be in the slot you
// assigned because there might have already been a filter in that slot.
// When registering, the next available higher slot will be used. You also need
// to pass in the instance currently in the slot you want to remove:
fmanager.deRegisterFilter(slot, addCommentFilter);
// Here is an example to remove all the filters,
// including the ones you did not register
for (Integer slot:fmanager.getUsedSlots()) {
fmanager.deRegisterFilter(slot, fmanager.getFilter (slot));
23.11 Using the RIDC JDeveloper Extension
The Remote Intradoc Client (RIDC) communication API is provided as a deployable extension for Oracle JDeveloper. The RIDC JDeveloper extension places a copy of the RIDC library in the JDeveloper environment.
This JDeveloper version and RIDC extension is required:
Oracle Remote Intradoc Client (RIDC) extension 11.1.1.6 (11gR1 PS5)
Oracle JDeveloper version 11.1.1.6 (11gR1 PS5)
The Oracle Remote Intradoc Client (RIDC) extension (oracle.ucm.ridc.jdev-11.1.1.6.zip) is located in the /modules/jdev directory of the Remote Intradoc Client (RIDC) suite distribution (ridc-suite-11.1.1.6.zip). The RIDC suite distribution can be downloaded from the Oracle Technology Network (OTN) at .
23.11.1 Deploying the RIDC Extension
Follow these steps to deploy the RIDC extension on Oracle JDeveloper:
Download the Remote Intradoc Client (RIDC) suite distribution from Oracle Technology Network (OTN).
Unbundle RIDC suite distribution (ridc-suite-11.1.1.6.zip) to a location on the system hosting your Oracle JDeveloper instance.
From the JDeveloper main menu, select Help then Check for Updates.
Enable the Install from Local File option.
Click Browse and navigate to the unbundled RIDC suite distribution (ridc-suite-11.1.1.6.zip).
Select the RIDC extension (oracle.ucm.ridc.jdev-11.1.1.6.zip) located in the /modules/jdev directory and click Open.
Click Next to deploy the extension.
Click Finish.
After JDeveloper has installed the extension, you can verify that the RIDC library is accessible to JDeveloper by selecting Tools & Preferences & Extensions and scroll to the RIDC entry. To verify the RIDC library is on the disk, check the directory &JDeveloper Home&/jdeveloper/ucm/Distribution/RIDC and confirm these files exist:
& +-- commons-codec-1.2.jar
& +-- commons-httpclient-3.1.jar
& +-- commons-logging-1.0.4.jar
& +-- httpclient-4.1.1.jar
& +-- httpcore-4.1.jar
& +-- httpmime-4.1.1.jar
+-- oracle.ucm.ridc-11.1.1.jar
+-- oracle.ucm.ridc.app-lib-11.1.1.ear
23.11.2 Creating a New Application and Project with RIDC Technologies
This topic describes the steps to create a new application and project, add RIDC technologies, and verify the shared library references. It is recommended that you create a new RIDC-enabled project rather than add RIDC technologies to an existing project.
From the main menu, select File & New.
The New Gallery dialog opens.
In Categories, select General & Applications.
In Items, select Generic Application.
The Create Generic Application wizard displays.
Provide an application name.
Accept the default directory or provide a different directory.
Click Next.
Provide a project name that identifies this as an RIDC-enabled project.
On the Project Technologies tab, select RIDC, HTML, and JSP and Servlets from the list and click the shuttle button to transfer each of these selections to the Selected list.
Click Next.
Review the settings and click Finish.
From the main menu, select View & Application Navigator.
In the Application Navigator, select the Application Resources panel.
Expand Descriptors & META-INF.
Right-click weblogic-application.xml and select Open.
In the editor, select the Overview tab.
Select Libraries and expand Shared Library References.
Verify that the Library Name oracle.ucm.ridc.app-lib is listed.
23.11.3 Working with Connections
This topic describes various procedures for working with connections. Refer to the RIDC section of the JDeveloper Online Help for more information on working with connections.
In JDeveloper 11g you have two ways of creating and managing connections. You can define a connection to be used in the context of an application (called an Application Resource connection), or for the IDE as a whole (called an IDE connection). You use the same dialog to define both of these connections, but their scope within JDeveloper is different.
Application Resources: These connections are locally scoped and just available within the application. The connection information is stored within the application itself, and can be deployed with the application. These types of connections are listed in the Application Resources panel of the Application Navigator, under the Connections node.
IDE Connections: These connections are globally defined and available for reuse. These types of connections are listed in the IDE Connections panel of the Resource Palette. You can copy IDE connections to the Application Navigator to use them within an application
From the main menu, select View & Application Navigator.
In the Application Navigator, select the Applications Resources panel.
Right-click Connections and select New Connection & RIDC.
Use the Create Content Server Connection dialog to create a new connection. Click Help for descriptions of the options and fields on this dialog.
Click Test Connection.
If the connection fails, verify that you have the correct connection information for the content server and have supplied valid login credentials.
From the main menu, select View & Application Navigator.
In the Application Navigator, select the Applications Resources panel.
Expand Connections & RIDC.
Right-click a connection and select Properties.
Use the Edit Content Server Connection dialog to edit or update the connection details for your connection. Click Help for descriptions of the options and fields on this dialog.
Click Test Connection.
If the connection fails, verify that you have the correct connection information for the content server and have supplied valid login credentials.
From the main menu, select View & Resource Palette.
In the Resource Palette, select the IDE Connections panel.
Expand the RIDC node.
Right-click a connection and select Properties.
Use the Edit Content Server Connection dialog to edit or update the connection details for your connection. Click Help for descriptions of the options and fields on this dialog.
Click Test Connection.
If the connection fails, verify that you have the correct connection information for the content server and have supplied valid login credentials.
From the main menu, select View & Application Navigator.
From the drop-down list, select an application with RIDC technologies.
From the main menu, select View & Resource Palette.
In the Resource Palette, select the IDE Connections panel.
Expand the RIDC node.
Right-click a connection and select Add to Application.
Note: The connection is added to the application currently open in JDeveloper. The connection is listed in the Application Resources panel of the Application Navigator, under the Connections node.
23.11.4 Example Service Call
This topic provides example code of a service call on a JSP page. These steps assume you have created a JSP page for your RIDC-enabled project. Refer to the RIDC section of the JDeveloper Online Help for more information.
Use these JSP page directives to your JSP page to import required java packages and classes:
&%@ page import="oracle.stellent.ridc.*"%&
&%@ page import="oracle.stellent.ridc.model.*"%&
&%@ page import="oracle.stellent.ridc.model.impl.*"%&
&%@ page import="oracle.stellent.ridc.convenience.adf.connection.*"%&
The code in
provides an example service call added to the body of a JSP page.
Example 23-20 Example Code for Service Call
&h1&Example of service call&/h1&
AdfConnectionFacade facade = new AdfConnectionFacade("demo");
AdfConnectionFacade.ResultTestC rtest =
facade.testConnection("user");
if (!rtest.isSuccess()) {
&h3&Content server not available because&/h3&
&p&&%=rtest.getmessaage()%&&/p&
IdcClient client = facead.getIdcClient();
IdcContext ctx = new IdcContext(facade.gtUserCredentials("user"));
DataBinder binder = client.createBinder();
binder.putLocal("IdcService", "GET_USER_PERMISSIONS");
DataBinder r = client.sendRequest(ctx, binder).getResponseAsBinder();
&pre&&%=(DataBinderImpl)r%&&/pre&
Scripting on this page enhances content navigation, but does not change the content in any way.