You are not logged in.
Hi
Just raised a support ticket as uploads via the API suddenly disappeared. What's happened is that a user on our system was moved to a more controlled access group so all the images are now sitting awaiting approval. Only problem is that the API upload process is nothing to do with that user so absolutely no idea why it's suddenly doing this. I'm told it's not a support issue and that it's a problem with our code.
The login script is here with the only parameters being the API url and the API key. I still can't think what the relationship is between the user and the API - the job has been running ok and all existing uploads via the API were not associated to the user.
Appreciate if anyone could help?
Thanks
Innes
public string Login(string ThirdLightApi, string ThirdLightApiKey)
{
Errors.ErrorType = "ThirdLightErrors";
string result = string.Empty;
try
{
var httpWebRequest = (HttpWebRequest)WebRequest.Create(ThirdLightApi);
httpWebRequest.ContentType = "application/json;charset=UTF-8";
httpWebRequest.Method = "POST";
using (var streamWriter = new StreamWriter(httpWebRequest.GetRequestStream()))
{
//using api key
string apik = ThirdLightApiKey;
string vers = "1.0";
string action = "Core.LoginWithKey";
string json = "{";
json = json + "\"inParams\":{\"apikey\":\"" + ThirdLightApiKey + "\"},\"action\":\"" + action + "\",\"apiVersion\":\"" + vers + "\"}";
streamWriter.Write(json);
streamWriter.Flush();
streamWriter.Close();
}
var httpResponse = (HttpWebResponse)httpWebRequest.GetResponse();
using (var streamReader = new StreamReader(httpResponse.GetResponseStream()))
{
result = streamReader.ReadToEnd();
return result;
}
}
catch (Exception ex)
{
logErrors("Login()", ex.Message, null, result, null, null);
return "";
}
}
Offline
Hi Innes,
In IMS, all actions are performed on behalf of a user. When logging in with an API key, you should first call Core.ImpersonateUser to select the user on whose behalf you are acting.
If you don't do this, then the first administrator account found will be used, which is what you are seeing.
Kind regards,
Dominic
Offline
Hi Dominic,
As both methods Core.ImpersonateUser & Core.LoginWithKey produces sessionid as output- in such case which session id we should be using
for any further activities in the upload process.
Thanks
Satish
Offline
Hi,
We have created a new admin user, and tried calling Core.ImpersonateUser with the user name, but I keep getting following error, not sure the reason behind this, can you please advise
Input:
{"inParams":{"userRef":"hubAdminUser"},"action":"Core.ImpersonateUser","lookupType":"username"}
Output:
{"result":{"api":"OK","action":"ACTION_NOT_PERMITTED"}}
Offline
Hi,
I tried calling "Core.ImpersonateUser" before login and also tried calling after core.loginwithkey call but still the same error
"ACTION_NOT_PERMITTED", please advise.
Thanks
Satish
Offline
Hi Satish,
You must call Core.ImpersonateUser using the session ID returned from Core.LoginWithKey. You should then use the new session ID in subsequent requests.
Dominic
Offline
Thanks Dominic,
It worked. I noticed that the session id returned is same as session id passed to this method. is that correct.?
"{"result":{"api":"OK","action":"OK"},"outParams":{"sessionId":"tGYsOd13cDj4SQ7PwxafdNKTGHs1twE6","userDetails":{"type":1,"userref":"1-23","username":"adminupload_user","description":"Admin Upload User","email":"abc.xyz@dom.co.uk","canPublish":true}}}"
Just to let you know that the api documentation is not clear on all parameters which must be passed to this method.
Api documentation on the method as below.
Core_ImpersonateUser
Core.ImpersonateUser(string userRef[, string lookupType = "id"]) → hash
string userRef - The user account's username, e-mail address or ID
string lookupType - The type of userRef - supported values are "email" "username" "id" or "userprincipal" (LDAP users only)
Returns hash
Returns a session identifier and some details about the user
- Satish
Offline
Hi Satish,
Yes, that is correct.
I would encourage you to use the sessionId returned in any case, as that is guaranteed to refer to the correct session - and potentially in the future it might not be the same.
Could you clarify what parameter is unclear? It looks to me like userRef and lookupType are accurately described.
Dominic
Offline
Hi Dominic,
We are facing this issue again that when files are uploaded using impersonated user the files are moved to "Required approval" state instead of stated folder. could you please advise why this has recurred.
Thanks
Satish
Offline
Hi Satish,
This will be because the user in question has some upload approval options set; this may have been changed via their group membership. If the option to require manual approval is set, or any metadata fields are configured as 'available' or 'required' in their upload settings then this would be the expected behaviour.
Dominic
Offline