HelloDFS DFS 6.5 dotnet example returns "Authorization failed, please review identities provided in

Hello,

Hope someone can help with this very frustrating problem. I am trying to run the HelloDFS dot net example from the DFS 6.5 sdk. We're running DFS on the Content Server (SUSE Linux) and the dfs consumer on a separate machine. I can invoke the QueryService web service from a browser window and it returns the WSDL, so I know my ip address is correct. The only changes to the sample code are filling in the repository variable, userName, password and address. When I step through it and get to the Query Execute line:

QueryResult queryResult = querySvc.Execute(query, queryEx, operationOptions);

the line throws a hard exception: {Service method "Execute" invocation failed}. The inner exception reads:

{"Authorization failed, please review identities provided in service context \"temporary /127.0.0.1-1233674717250-839111712\""}

I verified that the respository name, user, password, and address are correct, and the dfc.properties file is pointing to the Content Server box.

I'm completely confused about why this sample (and the others contained in the sdk dotnet examples) is throwing this error, particularly since I have not changed any of the code. Does anyone have a solution/suggestion for this problem?

Thanks!

Find more posts tagged with

Comments

david.matheson

This is the error that you will get if you don't set a token in the header of your client request. Please let me know how you are setting the token that you are getting from ContextRegistryService. Are you using the productivity layer?

ghs

Hi Dave,

Thanks for your response. I am using the productivity layer and wasn't aware that you had to set a token in the header in that instance. The code I'm using is listed below; the only lines I thought it was necessary to modify were the username, password, repository and address ... could you post a code example showing how to set the token?

-----------------------------------------------Begin Code ------------------------------------------------------------------------

namespace

HelloDFS{

/*** This class demonstrates how to code a typical request to a DFS core service(in

* this case QueryService). The code goes through the steps of creating a

* ServiceContext, which contains repository and credential information, creating

* a profile, which contains properties that determine how a service operation

* behaves, and calling the service with the profile.

* This sample assumes that you have a working installation

* of DFS that points to a working Content Server.

class

QueryServiceTest{

/************************************************************* These are the only values I modified in the code.

private String repository = "myrepository"

;

/* The username to login to the repository */

private String userName = "myusername"

;

/* The password for the username */

private String password = "my password"

;

/* The address where the DFS services are located */

private String address = "http://myIP:myport/services

;

/***********************************************************/

/* The module name for the DFS core services */

private static String moduleName = "core"

;

private

IServiceContext serviceContext;

public void

setContext(){

/** Get the service context and set the user

* credentials and repository information

ContextFactory contextFactory = ContextFactory.Instance;serviceContext = contextFactory.NewContext();RepositoryIdentity repositoryIdentity =

new RepositoryIdentity(repository, userName, password, ""

);serviceContext.AddIdentity(repositoryIdentity);

}

/** Demonstrates a typical scenario for calling the query service.

* Gets an instance of the Query service and calls the execute operation

* with a hard-coded query and operation options.

public void

callQueryService(){

/** Get an instance of the QueryService by passing

* in the service context to the service factory.

try

{ServiceFactory serviceFactory = ServiceFactory.Instance;IQueryService querySvc = serviceFactory.GetRemoteService<IQueryService>(serviceContext, moduleName, address);

/** Construct the query and the QueryExecution options

PassthroughQuery query =

new

PassthroughQuery();query.QueryString =

"select r_object_id, object_name from dm_cabinet"

;query.AddRepository(repository);

QueryExecution queryEx =

new

QueryExecution();queryEx.CacheStrategyType = CacheStrategyType.DEFAULT_CACHE_STRATEGY;

/** Execute the query passing in the operation options and print the result

OperationOptions operationOptions =

null

;QueryResult queryResult = querySvc.Execute(query, queryEx, operationOptions);

Console.WriteLine("QueryId == "

+ query.QueryString);

Console.WriteLine("CacheStrategyType == "

+ queryEx.CacheStrategyType);DataPackage resultDp = queryResult.DataPackage;

List

<DataObject> dataObjects = resultDp.DataObjects;

int

numberOfObjects = dataObjects.Count;

Console.WriteLine("Total objects returned is: "

+ numberOfObjects);

foreach (DataObject dObj in

dataObjects){

PropertySet docProperties = dObj.Properties;

String

objectId = dObj.Identity.GetValueAsString();

String docName = docProperties.Get("object_name"

).GetValueAsString();

Console.WriteLine("Document " + objectId + " name is "

+ docName);}

}

catch

(ServiceException e){

Console

.WriteLine(e.Message);}

}

public static void Main(String

[] args){

QueryServiceTest t =

new

QueryServiceTest();

------------------------------ End Code -----------------------------------------------------------

Thanks for your help,

George

david.matheson

Hi, George. If you are using the productivity layer, you don't have to set the token in the header, it does it for you. If does it for you right at this line:

IQueryService querySvc = serviceFactory.GetRemoteService<IQueryService>(serviceContext, moduleName, address);

I would check that your serviceContext contains a RepositoryIdentity object with the correct credentials. Perhaps leave the domain "null" instead of empty string.

ghs

Dave,

Thanks again for the quick response. I tried setting the domain to null instead of the default empty string, but got the same error. Since I get the same error running the other .NET examples in the sdk, it seems like it is a security issue. I'm sure I'm using the proper credentials ... do you have any other suggestions?

This example is as simple as it gets, and since I didn't modify any of the code, I would expect that it would just work out of the box.

George

david.matheson

I would create a new project with none of the productivity layer DLLs, add the ContextRegistryService (should be at http://yourip:yourport/services/core/runtime/ContextRegistryService?wsdl) as a service reference in Visual Studio, then code up a simple client using the credentials that you specified below. If it gives you a token back from the "register" method, then you know that this part is working, at least. If it's not, then there is something wrong.

however

I have had the same issue.

Really annoying.

What worked for me:

I added ~ all jars from %SDK%/lib/java/jaxws to the project as a library.

I don't really know how or why, but this cured my authentication problem.

ALTAMIRANO

I have the same problem with the sample dotnet and I could not solve it, try to replicate the solution. But I do not understand how to integrate the jaxws libraries to the project or are working with the example in java.

You could tell me step by step how you did it?

Thanks

however

Indeed, I work in Java, so these includes won't work in .net.

However, my experience is that there can be just too many reasons for authentications failures, which are really hard to detect. The most annoying was for me, when I could not connect because of different date formats on client and server. (dfc.date_format=yyyy.MM.dd HH\:mm\:ss in dfc.properties helped in this case).

david.matheson

OK, However was talking about getting this working in Java, not in .NET. I haven't had any problems with dfc.date_format or anything like that. Here's what people should do if they are having authentication problems:

Check your DFS installation

Look for dfc.properties (in emc-dfs/WEB-INF/classes if you are using the .war file) and make sure that it is pointing to whatever content repositories that you want (it can point to Content Server v5.3 and above). The dfc.properties in the .war file has all the things you need. Just change it to suit your environment. Read the DFC documentation for everything, but here are the most important settings (any other Documentum product installation will have to have these settings, usually in C:\Documentum\config, just check Webtop or whatever else you have):
- dfc.docbroker.host[0]
- dfc.docbroker.port[0]
- dfc.bof.registry.repository
- dfc.bof.registry.username
- dfc.bof.registry.password
- dfc.data.dir (make sure this directory exists!)
Restart whatever Tomcat instance is running DFS (or JBoss, or WebLogic, etc.).
Make sure you can log in to the content repository with whatever username/password you want to try. Do this through Webtop or Repoint.
Make sure you can log in to the content repository with whatever username/password you have for the BOF registry user (aka the Global registry user). This is usually dm_bof_registry. The password specified in dfc.properties is encrypted. Use com.documentum.fc.tools.RegistryPasswordUtils to check that it's correct (you can't go backwards, you have to know the password and then verify it, and "=" is escaped as "\=").
Note that in the same directory there is log4j.properties. Change all instances of WARN to DEBUG, and make sure C:\Documentum\logs exists, and you will get some logging to help you figure out what's going on.

Java

If you choose Java, go grab JAX-WS (https://jax-ws.dev.java.net/)
Set up an Ant script to wsimport the WSDL of the ContextRegistryService. You could also use Maven to do this, if you're familiar with it (add the dependency, configure the plugin, mvn compile).
Code up a client based on the generated code, passing a RepoInfo object with the same info you tested above to the ContextRegistryService's register method.
If you get a valid (i.e. not temporary) token, then you're good.

.NET

Crack open Visual Studio and create a new project (class library will do).
Add a Service Reference (not a Web Reference) and point it to the ContextRegistryService WSDL.
Code up a client based on the generated code, passing a RepoInfo object with the same info you tested above to the ContextRegistryService's register method.
If you get a valid (i.e. not temporary) token, then you're good.

This is only to make sure that you can authenticate through DFS. It does not cover what you do with the token (inject it into the SOAP header of subsequent requests). Hit up the log file C:\Documentum\logs\dfs-runtime.log if you are still having problems. If this is not helping you out, then message me.

csebourn

Hi,

Does your stack trace include the following error message:

Caused by: java.lang.NoClassDefFoundError

at sun.reflect.NativeConstructor.AccessorImpl.newInstance0(Native Method)

If so, this problem is due to some missing DFC jars in your ear file (bug DFS-733).

To correct this, in your build.xml file, change the <packageservice><pathelement> for DFC by changing the DFC.jar to *.jar to include all jars in this directory as follows:

Re-package and re-deploy your ear file.

Please let me know if this solves your problem.

Thanks

ajaxnetguy

My installation is good. I am still getting the same error.

==============================================================================================================

Server stack trace:at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)Exception rethrown at [0]:at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)at Emc.Documentum.FS.Services.Core.QueryServicePort.execute(executeRequest request)at Emc.Documentum.FS.Services.Core.QueryServicePortClient.Emc.Documentum.FS.Services.Core.QueryServicePort.execute(executeRequest request)at Emc.Documentum.FS.Services.Core.QueryServicePortClient.Execute(Query query, QueryExecution execution, OperationOptions options)

==============================================================================================================

Can you please supply a sample code? Thanks.

zhou_simonq

which application server do you use? Are you using OOTB installation of DFS? Can you consume the standard DFS services, such as object service, schema service, other than the customized services?

- simon

ajaxnetguy

i am using default JBoss DFS installations that comes together with the content server.

I can consume other services such as object service, schema service, etc.

I am unable to browse through http://hostname :9080/services .

zhou_simonq

Can you access http://server_name:9080/services/core/ObjectService?wsdl

BTW, pls check dfc.properties in DFS deployment package.

- simon

ajaxnetguy

yes, the web service returns the wsdl.

i am using the dfs via the default jboss installation of the content server.

for dfc.properties in the dfs deployment package, i assume you are referring to the dfc.properties file found in C:\Documentum\jboss4.2.0\server\DctmServer_MethodServer\deploy\dfs.ear\APP-INF\classes.

#include C:\Documentum\config\dfc.properties
dfc.exception.include_id=false
dfc.exception.include_decoration=false
dfc.session.allow_trusted_login=false

This file file also references values from the default config file of the content server found in C:\Documentum\config folder (i.e. df.properties).

dfc.data.dir=C\:/Documentum
dfc.search.ecis.enable=false
dfc.search.ecis.host=
dfc.search.ecis.port=
dfc.security.keystore.file=C\:/Documentum/config/dfc.keystore
dfc.session.secure_connect_default=try_native_first
dfc.tokenstorage.dir=C\:/Documentum/apptoken
dfc.tokenstorage.enable=false
dfc.docbroker.host[0]=myServer
dfc.docbroker.port[0]=1489
dfc.docbroker.host[1]=myServer.mydomain.com

dfc.docbroker.port[1]=1489
dfc.globalregistry.repository=myRepositoryName

dfc.globalregistry.username=dm_bof_registry
dfc.globalregistry.password=myEncryptedPassword

I am using a different username/password combination for connecting to using DFS. this user/password combo is a supersuser/admin in the content repository. does this matter? have tested using the dm_bof_registry credentials for my repository identity, it also fails.