Expand my Community achievements bar.

beginner API and StreamClientSample.php

Avatar

Level 10
I've just started to look into APIs and had downloaded the StreamClientSample.php. Based on the code, I suppose I have to change the text in blue to my instance. $client = new StreamClient(' http://localhost:8080 '); Why is this pointing to port 8080 though? Should it not be just https://xxxx.attask-ondemand.com? The next code that I thought I needed to change are the username and password. write('Logging in...') $session = $client->login(' username ', ' password '); And I think this is where I am having issues when I run StreamClientSample.php. It will give me an error of Logging in...Error: Failed to connect to xxxx.attask-ondemand.com port 443: Timed out Any ideas why it's timing out? I know that the code sample is quite old so I'm not sure if the src\StreamClient.php and StreamClientSample.php is still usable. If anyone can point me to the right direction? Thanks!
5 Replies

Avatar

Level 10
Answering my own question in case there are other systems administrators who are interested in starting on API and testing StreamClientSample.php: Yes, change localhost:8080 to your instance, remove port. Yes, change to username and passwd (change your password to something else first for testing as I find this insecure). Timing out is caused by firewall as I am testing the instance from my machine and not on company server and most likely the port is not allowed to send out a request call behind the firewall.

Avatar

Level 2
Some of the code samples (e.g. C#, python) explain to swap out the URL to include your instance, and some don't. Unfortunately, not all samples were created the same so there are inconsistencies. The samples were first created as internal use items, and the "localhost:8080" is just holdover code from the way we run the product locally on our dev machines. You are most likely correct on the timeout being a network issue. Port 443 (https) timing out should just mean you can't currently connect to the instance from your current network. For the username/password topic, I don't feel like the php code sample accurately reflects what we suggest long-term for customers. As you start building out integrations, we highly suggest that our users utilize API keys instead of username/password connections. Sorry I didn't see this one yesterday! Please feel free to reach out with any other questions.

Avatar

Level 10
Thanks Haven for the reply. I actually could use more working code samples, html samples of how simple APIs are used to speed up my learning. Would you have those? As to the APIKey, my understanding here is that in the script, you will always need to append &apiKey=xxxx as sort of the login. Is this correct?

Avatar

Level 2
Thanks Haven for the reply. I actually could use more working code samples, html samples of how simple APIs are used to speed up my learning. Would you have those? As to the APIKey, my understanding here is that in the script, you will always need to append &apiKey=xxxx as sort of the login. Is this correct?
Polly, The two main external resources we have are "https://developers.workfront.com/api-docs/">The API Docs and "https://developers.workfront.com/api-docs/api-explorer/">The API Explorer . We also appear to have API Bootcamp that is held periodically depending on client interest. Unfortunately, I've been unable to determine who actually owns that training as it only happens a few times a year. If you are interested in the Bootcamp, I'd suggest submitting a help desk ticket requesting more information. You are correct about the " &apiKey=xxxx" comment. You can think of this type of authentication as transactional. Each transaction is required to have the 'apiKey' field to authenticate the request, and as soon as the request is finished you are no longer authenticated. Within Workfront there are a few options for API Key expiration, clearing, etc., which is documented on our"https://support.workfront.com/hc/en-us/articles/218484047"> support site . While there are other authentication methods, each of them has its own drawbacks. Here is some short information on those types: "https://developers.workfront.com/api-docs/#Login">Login (username/password): This is generally discouraged as locally (before transmit), you are putting that information in plain text. There are a lot of security reasons why this should be avoided. The most simple one is browser cache/history. "https://developers.workfront.com/api-docs/#Cookie">Cookie : While it is possible to get your current login cookie and provide it to the API for authentication, You can only perform GET calls using this method for security reasons which are explained within the link. "https://developers.workfront.com/api-docs/#SessionID">Session ID : After a successful login you will be given a session ID. That session ID can also be used to authenticate. Once you logout that session ID is now invalid, and a new login will provide a different session ID. This first requires some other sort of login, which is why it's not commonly used. I have seen some scripts which use login, and then store the session ID and use that for follow-up requests. For the future, we have plans to switch to SSO/SAML/OAuth methods for security reasons, but those are currently unavailable. I hope this helps!

Avatar

Level 10
Haven, the explanation on the authentication methods does help as I try to think of ways on how to move forward with API scripts. Thanks.