Hi Vincent,Can you double check that the user is part of a user group that is assigned a role that provides access to the task in question? And can you try to clear your cookies to ensure that you are actually signed in as the correct user and not as another user from a lingering authentication cookie?We verified my user’s rights, the rights of the user groups assigned to me, roles, everything points to me having permissions to call and access this task. I have also refreshed my authentication cookie multiple times, to no avail.If you're testing against an SF metasource, another option is that the task is new and Indicium has not reloaded its internal application model. Indicium cannot detect model changes against SF metasources so the only way to force a refresh is to call the /refresh_model endpoint with a POST request or to log out and log back in.This task has existed for several years, so it should have been detected by now I would guess.😁A third option is that you're calling the
Hi @Jeroen de Klerk, is there a specific reason you want to use a task? I am asking this, because calling a task requires resource-staging (Resource Staging | Thinkwise Documentation (thinkwisesoftware.com)) If/when you need this, great, but for API's that need to perform a singular 'thing’ I usually use a subroutine (procedure) instead. This is a lot more straight-forward and you can do this in one go instead of creating a resource and the committing it. Hi Robert!We use a fair few tasks, as our API forms a BFF (backend-for-frontend) for a mobile client using a subset of our Thinkwise apps’s functionalities. This normally works fine when a task is linked to a subject, but we now seem to be running into issues with tasks where this is not the case.The logs seem to provide no additional information on what’s going wrong, other than “No suitable candidates were found for ‘/<task>’”. This suggests the task I am trying to call does not exist, however I have checked and verified it
Hello Jeroen, I don't have a whole lot of experience on this topic, but did you happen to look into the Documentation on this topic? This page might help you to check whether the way you call upon the task is correct: https://docs.thinkwisesoftware.com/docs/indicium/api#crud-operations-functions-and-procedures Also, checking the Indicium log might help to figure out what is going wrong. Did you look into that as well? Kind regards, Renée Hi Renee,Thanks for the quick response and for the pointer to the docs.The way I am calling the task seems to be correct, I have tried prepending it with task_ as well as just using the task name, both return a 404. The parameters I have sent in the request body are correct as well.It seems there is something else going wrong, I will have a look at the logs as you suggested.Thanks!
I have actually been hoping for this for a long time now! :D
We are currently running into issues using cookie authentication within our application.After coming across this post, it seems this could work, but one thing seems unclear, so perhaps a follow-up:The answer to this question reads as though these OAuth JWT tokens are client based (so we would be authenticating the application itself as a client with Indicium), however we require authentication for specific users within the Thinkwise application.Therefore our question is; are these JWTs specific to a user, or are they only for authenticating a client?
Hello Vincent, Thank you for the swift reply!I have created an idea on the Community Portal as you requested!Hopefully the requirements and general description are helpful.Please find the link below:
The problem has been found. The Indicium error occured because of an apparent improperly defined request.After properly composing the request according to @Benjamin Westra's answer, a different fault altogether appeared, which is to be resolved in the instead of trigger.
Hi Jeroen, thank you for posting your question. Have you tried to supply the correct filtering in the URI, and try to leave out the PK values in the message body. Let me know if this helps. for reference : https://docs.thinkwisesoftware.com/docs/indicium/api Just tried this, this does give me a 204 No Content response, but it does not seem to actually change any values.There is an instead of trigger on the view for updates, perhaps the actual error is in there, however updating the same values in the Windows GUI seems to work just fine.
Hello @Vincent Doppenberg, Thank you for the swift reply! Staged resources almost never use a noteworthy amount of memory. The typical staged resource probably uses less than a kilobyte of memory. Blob and clob data types such as varbinary(max) and varchar(max) do allow resources to potentially use a lot of memory. We are looking into the possibility of allowing a maximum length setting on these data types as well. It's important to add here that files which are uploaded to a staged resource using /upload_<file_property_id> are never stored in memory in their entirety. Instead they are streamed to a file cache and then streamed to their final location upon committing the resource.That is good to know. Our API limits the max number of incoming requests from a single IP per minute, so it would be very difficult for someone to (purposefully) overload Universal’s memory through it with such a low memory footprint per staged resource. We recommend recycling Indicium periodically as a
Hello Jeroen, Indicium Universal also offers an API to execute tasks in a single request (and the same goes for inserts, updates, etc.). When executing the task without any context (i.e. not in the context of a selected record), the API is simply this: POST/my_task_id{ "my_task_parmtr_1": 123, "my_task_parmtr_2": "abc",} When executing the task in the context of a selected record, the API is this: POST/my_table(my_pk_col_1=123, my_pk_col_2='abc')/task_my_task_id{ "my_task_parmtr_1": 123, "my_task_parmtr_2": "abc",} Please note the task_ prefix before the task_id in this example. These APIs are documented here. And I have written a blog post on this specific topic here. Please note the Simplifying the APIs paragraph. For these APIs it is important to realize that you should only supply the task parameters that the user would enter in the request body. Tasks parameters that receive their value through the table-task link, default values of the task parmtr, default procedure or e
Hi Vincent, Thank you for the thorough explanation!Just to confirm, by "knowing beforehand which value you are going to patch”, do you mean already knowing I'm supplying value 556 for reason_id, as opposed to looking it up in a lookup table first? Thanks again!
In my opinion, this should be a no-brainer. Regardless of the context, searching on multiple keywords like this seems like basic functionality to me.However, it is difficult to determine whether to search inclusively (using OR) or exclusively (using AND). In other words, do we want the results to match both keywords or do we want them to match either one keyword or both. In the most general sense I would assume using OR would be the go-to. Perhaps this should be a dropdown, where the end-user themselves can opt whether to search inclusively or exclusively?In either case, implementing this should be as simple as splitting the input on a whitespace character and inserting each resulting item into the query as a separate LIKE-clause.Following @htimmermans’ example;WHERE [dbo].[item].[field] LIKE '%Kleppe%' OR '%afstel%'Above example assumes inclusive searching, exclusively the OR would be replaced with AND in the above clause.The debugger shows the search string is direct
Call /account/api/login without a Basic Authorization header (instead, you supply the username and password in the form-data POST body.Save the cookie from the Set-Cookie response headerThat was it! I was supplying the user/pass combination as a JSON body, not as form data. Changing it to that fixed it. Going to work this into the API now and see about providing the cookie to the Indicium request.How long would these cookies be valid for? Or is that a per-instance configuration? If the expiry time is limited, we will need to introduce a refresh method into our API.In both of these scenarios you could choose to call POST /account/api/logout at the end of a user session, but the only thing this does is return a Set-Cookie response header with an empty cookie to override the user's authentication cookie. As said before, there is no server-side state that makes logging out necessary, however it will cause the Ends on column in IAMs Session log to be filled out, if you're interested in that
Are you supplying Basic authentication through Postman as well? You should do one or the other, not both.I am trying to log in using the basic auth header only, yes. I tried using the request body instead, but it kept saying the UserName-field was required even though I had supplied it and named it correctly in the JSON.Could it be that Indicium is having trouble authenticating my account because it is a domain account? The account I use in Indicium is the same I use to log into Windows, remote desktops and everything else I have access to in my organisation. Could Indicium be detecting that I am logged in to my domain account in Windows, for example, and therefore think I am already logged in?If we're talking about a few hundred requests spread over a day, then I don't think it's that big of an issue. However, if it will be more like a few dozen requests every minute, then I would definitely recommend the cookie approach.Cookie approach it is. The clients using the API are making well
Hello Jeroen, If you want to log in to Indicium Universal by means of an API call with a username and password, then there are two options: The preferred method uses cookie authentication. This means that you send a login request to an endpoint and in return you will receive a cookie that serves as an authentication ticket for some time. For this to work, it is necessary that the client has some way of keeping track of the cookies and sending it along with subsequent requests (like browsers do). You can send a form-data POST request to /indicium/account/api/login with the parameters UserName, Password and optionally RememberLogin. Logging out can then be done by sending a POST request without a body to /indicium/account/api/logout. The only thing that this request does is clearing the cookie. You can still use Basic authentication as well, but ultimately this will also return a cookie that serves as an authentication ticket. The idea is that you only add the Basic Authorization hea
In the universal version the login seems not directly to be related to the apps. You'll first need to login and then get the available apps per environment. Next you can get the data. There is an api for logging in: /indicium/account/api/login With this link you can authorize yourself against your indicium instance. If you want the app then you'll need to call more API's There is an OpenAPI implementation available for all applications so you can see which endpoints there are. The Open API spec will definitely help, cheers!I tried calling the URL you specified, but it returns a 404 response. Our IIS site for Universal is named indicium_universal, so I assume in my case I would need to POST to http://<server>/indicium_universal/account/api/login with either a basic auth header or a user/pass combination in the request body?
Notice the Web GUI doesn't allow you to work with multiple GUI's in the same browser. Others will be logged off.If the user's main instance is logged off when another is opened in the same browser, it seems very tedious to run these tasks from an e-mail with automatic authentication in general.The user could be doing other work while waiting on the e-mail. If he then clicks the deeplink, all his work is lost as the instance will be automatically logged off. Unless I misunderstand the inner workings of the web GUI as you described, this renders automatic authentication in deeplinks as more of a hazard than an addition to a smooth workflow.I think we should let it up to the user to tell the browser to remember their credentials. That's the safest way to store the credentials in the client.This depends on how the client remembers passwords. A lot of people are using third-party tools such as Dashlane or 1Password instead of their browser's built-in credentials vault. Most of those tools d
There are many ways for this to be done.One would be, as you suggested, to have the login process store a local cookie in the browser, which is queried for in every request to check if a user is authenticated and/or authorized for the current request. However, cookies are becoming an increasingly outdated technology and may not be the safest solution, depending on how the user's browser handles cookies. Another solution could be to incorporate a special query parameter in the link behind the login button, containing a unique SHA256 hash string. This hash is simultaneously stored somewhere in the application, along with minimal information specifying the user authorized for the request.That way a user can click the deeplink in the email, without any form of authentication on the user's end. And guesstimating a SHA256 hash is significantly harder than intercepting a basic auth header and decoding the Base64 string, especially when a predetermined salt is used for the hashing algorithm. A
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
