nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Ticket could not be found when calling callback handler

amolina

Caused by: org.alfresco.webservice.util.WebServiceException: Ticket could not be found when calling callback handler.

What does it means?

Thanks!

Find more posts tagged with

Comments

doblek

In order to use Alfresco Web Services you MUST establish a valid session with the repository (which will return a ticket). See the "Starting a Session" section in this link.

That's all I could think of (without having seen your code). Maybe you can get more help if you post the code that heads to that exception…

Regards,
Enrique

andy

Hi

It is possible to get ticket issues when using clustering and the caching is not configured correctly. See the wiki docs if you are using clustering.

Andy

pietro

In order to use Alfresco Web Services you MUST establish a valid session with the repository (which will return a ticket). See the "Starting a Session" section in this link.

That's all I could think of (without having seen your code). Maybe you can get more help if you post the code that heads to that exception…

Regards,
Enrique

Hi,
suddenly we got the same error.

In random way it gives us error and (i.e.) fulltext search doesn't work.

The following operation may works or not.

We surely pass the right ticket, and we check it via rest call every time.

Login always work.

The problem always raise during all other operations:
fulltext search,getStoreRef, delete, insert, create,update.

Our logic is quite simple:
A webapp, we always call webservice getStoreRef() method, passing ticket as password.

It may crash or not.

If we re-authenticate every time before getStoreRef everything works ok, but we create a lot of ticket for a single session.

The fact we can't really understand is why if we pass the same ticket the following operation it may work as it's not a ticket problem.

Please help us, it's a lot of time we are looking for a solution

Thanks in advance
Pietro

mwildam

I know, this is an old issue - but I suddenly experience it from one moment to the other when issuing a search like this:

Query qt = new Query(Constants.QUERY_LANG_LUCENE, "PATH:\"app:company_home/\"");
try
{
    Node[] nodes = repositoryService.get(new Predicate(null,spacesStore, qt));
    for (Node node : nodes)
    {
        results.add(getNodeAttributes(node));
    }
    return results;
}‍‍‍‍‍‍‍‍‍‍

And that worked half an hour before and since then nothing helps, not even a reboot (I am on community 3.3g under Ubuntu 10.04).

mwildam

The line

Node[] nodes = repositoryService.get(new Predicate(null,spacesStore, qt));‍

is the exact location where the exception occurs an I have no idea why. I start and end sessions as intended and shown in the link given earlier. And again: It worked half an hour before.
The only thing I remember is that I got an update from Ubuntu repositories for OpenJDK, but Alfresco is using the Sun JRE 1.6.0_20 (as installed and configured) so I can't believe that it has something to do with that.

I also tried again with the older remote SDK (from 3.2r2) and same effect.

mwildam

Here is the complete stack trace:

WSHandler: password callback failed; nested exception is: 
        org.alfresco.webservice.util.WebServiceException: Ticket could not be found when calling callback handler.
    Trace: 
      Exception: org.apache.ws.security.WSSecurityException
      Message: WSHandler: password callback failed; nested exception is: 
            org.alfresco.webservice.util.WebServiceException: Ticket could not be found when calling callback handler.
        at org.apache.ws.security.handler.WSHandler.performCallback(WSHandler.java:736)
        at org.apache.ws.security.handler.WSHandler.readPwViaCallbackClass(WSHandler.java:712)
        at org.apache.ws.security.handler.WSHandler.getPassword(WSHandler.java:670)
        at org.apache.ws.security.action.UsernameTokenAction.execute(UsernameTokenAction.java:35)
        at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:197)
        at org.apache.ws.axis.security.WSDoAllSender.invoke(WSDoAllSender.java:170)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.client.AxisClient.invoke(AxisClient.java:127)
        at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
        at org.apache.axis.client.Call.invoke(Call.java:2767)
        at org.apache.axis.client.Call.invoke(Call.java:2443)
        at org.apache.axis.client.Call.invoke(Call.java:2366)
        at org.apache.axis.client.Call.invoke(Call.java:1812)
        at org.alfresco.webservice.repository.RepositoryServiceSoapBindingStub.get(RepositoryServiceSoapBindingStub.java:1078)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

hsohaib

This a problem caused by the use of ThreadLocal to store your authentication Details by Alfresco Web service API. the call for "repositoryService.get(new Predicate(null,spacesStore, qt));" is sometimes executed in different Thread than the one used to authenticate, and therefore AuthanticationUtils can't retreive the Ticket used.

WorkAround : Once authenticated store your AuthenticationDetails in the user's session, and before you call a webservice operation pass the authentication Details to AuthenticationUtils :

Authentication :

AuthenticationUtils.startSession("user", "password");
request.getSession().setAttribute("authenticationDetails", AuthenticationUtils.getAuthenticationDetails());
‍‍‍‍

your code becomes :

AuthenticationUtils.setAuthenticationDetails((AuthenticationDetails) req.getSession().getAttribute("authenticationDetails"));
Node[] nodes = repositoryService.get(new Predicate(null,spacesStore, qt));
‍‍‍‍

Might not be the best practice, but it avoids creating multiple tickets, and faster than re-Authenticating every time you use a webservice operation.

mwildam

What is req or request in your case?
I was assuming that if I retrieve the repositoryService from the WebServiceFactory after login, I am fine because it handles the session internally.
And I don't find the getSession method anywhere.

hsohaib

the "request" is HttServletRequest in your servlet or controller, its juste for saving the authenticationDetails for later use, of course you can use a session scope bean to store it instead if you're using Spring.

I was assuming that if I retrieve the repositoryService from the WebServiceFactory after login, I am fine because it handles the session internally.
And I don't find the getSession method anywhere.

That's true only if all your subsequent calls to webservice operations occurs in the same thread, which is not guaranteed.
So instead of storing the ticket in ThreadLocal we are storing it now in user's session.

to sum it up : when you call "AuthenticationUtils.startSession(user,pass)" , the ticket is stored in threadA, when you call a webservice operation from threadB, the API calls AuthenticationUtils to get the ticket, however there is no ticket stored in threadB and an exception is thrown.

mwildam

Indeed I am using several threads in my app. I am using the Alfresco Remote APIs - should I start a new session for every separate thread?
I did not yet understand what happens if I use AuthenticationUtils - can I get the authenticationdetails via that class for different threads? - I guess no.

hsohaib

You could either :
1 - start new session for for every separate thread.
2 - store authenticationDetails in the user's session, and use it to call the webservice (the code i provided in previous post).
3 - Modify AuthenticationUtils to store authenticationDetails in session instead of ThreadLocal, rebuild the SDK.

but that depends, are you using the remote API on a web application or a standalone one ?

mwildam

Thank you very much!
Caching the AuthenticationDetails and setting them just again using AuthenticationUtils.setAuthenticationDetails from the other thread helped.

mwildam

I am not the OP so I can't set the topic to [SOLVED].