I develop an AC/SpringBoot Jira plugin which needs to store properties in the host application. Atlassian provides Hosted Data Storage which I like to use.
I ran a test via Firefox RESTClient to play around with this feature.
When issuing a GET request to this URL:
https://kuespert-dev.atlassian.net/rest/atlassian-connect/1/addons/<MY-PLUGIN-KEY>
while being logged in to my Jira/Cloud instance on another tab everything is fine: I get back information about my plugin, including the key.
However, when issuing a PUT request to set a variable (like described in the documentation mentioned above) using this URL:
https://kuespert-dev.atlassian.net/rest/atlassian-connect/1/addons/<MY-PLUGIN-KEY>/properties/testProperty
and this request body:
{"string":"string-value","number":5}
as well as the required header:
Content-Type: application/json
I get back this response:
{
"status-code": 404,
"message": "Add-on with key does not exist."
}
This is a bit irritating, since the first REST call did find my plugin while the second to the sub-resource did not.
A similar question was already asked on the 'Atlassian Community' site, but no solution was found until today.
Maybe it's just a wrong error message or something similar. Does anybody here have experience with the 'Hosted Data Storage' feature and can help?
Thanks,
Matthias
Related
First off, I apologize if I use any incorrect terminology. I'm familiar with calling internal apis, but this a side project and new territory for me.
I've been using chrome debugger and powershell to write some scripts against the api of a public site. I was able to retrieve the JWT token, however after a few minutes my calls will start to fail with a 403 error. To get around this I've been exporting all the request headers from chrome and storing those locally for my script to pass whenever my call to the api fails. I narrowed it down to 4 headers that must be present, the one that is most suspect seems to be "cookie".
I then removed all key value pairs in the cookie header until I found the one that makes it fail. It's named "__cf_bm". A quick google says it's some kind of cloudflare bot management data. I don't see any of the data present in the __cf_bm cookie being sent in a response during authentication, I only see it in request headers. Is it not possible to construct this value? Does this essentially prevent me from interacting with the site's api?
When I tried to see data through try it out functionality then it is showing the following error
Error: Network Error
Check the developer tools console, it might have more information on the error.
If you are using an Adblocker, it is possible your Adblocker is blocking the request.
I also tried after disabling adblocker but it also does not work
console showing like this
Why this is happening and what is the solution for this?
Thanks in advance
Try the url in your browser with the API key. You can see the response.
Example :
https://api.themoviedb.org/3/movie/popular?api_key=your_api_key
Found out this is due to extension 'stoplight' in their site. Site Manager has said
"I believe Stoplight has temporarily blocked the "Try it out" feature for our account because too many people were using it as the source
for their apps, and not using api.themoviedb.org for some reason. No
timeline on getting it restored, but that's the problem. - Travis Bell"
follow this thread, In case it gets sorted in future.
https://www.themoviedb.org/talk/600184fc6aa8e0004077e364?page=1#6001bbacbe4b36003d514ac3
Apparently it depends on the way you try to access the data.
In my React application I was using Axios.Which ended up with ReferenceError: response is not defined. (got no response)
Afterwards I tried using the javascript fetch API. It worked good for me
So if you are trying to use it in an app you might want to use the fetch API. If you just encounter network error while using Try it out function on site - then you can copy the link and paste it directly, it should work fine.
Currently, I am using it in my dashboard and I have JWT authentication for the API that I'm using. I have implemented the interceptor to update HTTP HEADERS so I saw I'm passing a header name 'token' and checked there if any unnecessary headers were given or not with not accepting the TMDB API server. So I have sent a clean HTTP request and it's working fine.
All you have to just remove the unnecessary HTTP HEADERS
https://new-console.ng.bluemix.net/docs/services/apiconnect/apic_tutorial.html#apic_tutorial_01
Follow previous link to do create loopback project named ibmsvt and do test locally, we can post and get.
then publish this api as running api app on bluemix and we will get api target url and tls file.
type url and tls in api designer invoke, and publish api product again.
check api connect service and we can find that published api product has been published, configure developer portal, and invite developers
login developer portal and register one app
subscribe app to api product and run post command.
We will see that we only get can't post error information...
Please see attachment info for error info and api file.
From the screen capture provided, it looks like you're displaying the logs for the loopback application deployed on bluemix. It also looks like the POST request from APIConnect hit the Bluemix application as well. However, I'm unable to see the exact message of the error. What error did you get when you execute the POST from APIConnect? I suspect the POST did not include the $(request.path), what did you change the invoke url to be ? Can provide the x-ibm-configuration section in your yaml file? It will be located in your /definitions.
Thanks and best regards,
I am just have the exact problem, and struggled for days on redoing the tutorial several times, but still met with the same problem until found the upper reply, and gave me a hint.
In the tutorial, it says like the following:
Update the following fields with the values you copied previously:
Invoke URL: Insert the API target URL. You must specify the secure protocol HTTPS. For example:
apiconnect-ca3283b0-525c-488d-993b-3ab72fca78d0.youremail-dev.apic.mybluemix.net
TLS Profile: Insert the API invoke tls-profile.
For example:
client:Loopback-client
The origininal URL is $(runtime-url)$(request.path)$(request.search).
And the correct URL after updating is like following:
https://apiconnect-ca3283b0-525c-488d-993b-3ab72fca78d0.youremail-dev.apic.mybluemix.net$(request.path)
no slash before $(request.path), and $(request.search) should be deleted.
I also checked a tutorial video, it also do like this, but the screen for this step is passed away very quickly, you will not pay attention to this detail normally.
https://www.youtube.com/watch?v=Qku71JLv8vA&list=PLFa8jnU0KqE2eW5E449ziaurv8obSbcou&index=3&cm_mc_uid=24774488665514672571374&cm_mc_sid_50200000=1468400063
I'm looking to write a philips hue service that needs to allow users to register their hue bridge with my service. This service would change the color of bulbs based on an event. I'm aware that I can use IFTTT but in this scenario, I'd like to not use IFTTT and I'd like to register my website with philips hue's apps.
Any idea how I can do this? Your help is very much appreciated. Thanks!
EDIT: Not sure why I was down voted but I definitely did do my research. I looked on philips hue's developer website and couldn't find anything that was explicit on their APIs. I also looked through the iOS SDK and didn't see any methods that would trigger the pairing routine for remote devices. So far, the only example I have of this working (outside of Philips' products is the IFTTT service, which allows for an entry to be added into the 'My Apps' section).
TLDR: I wrote an API: https://github.com/jarvisinc/PhilipsHueRemoteAPI
I answered this question on my technical blog (http://blog.paulshi.me/technical/2013/11/27/Philips-Hue-Remote-API-Explained.html), which I will post here:
The question actually comes as two part:
Authentication
Remote Control
Authentication
I haven't figure out a reliable way to do authentication automatically. The following procedures needs to be automated: The idea is to fake as official iOS APP which has the ability to control remotely when enabled. We will need to get BRIDGEID and ACCESSTOKEN to pass the authentication step for remote control.
Find your BRIDGEID from https://www.meethue.com/api/nupnp. (or in My bridge page on the meethue website and by clicking on "Show me more")
Get ACCESSTOKEN
www.meethue.com/en-US/api/gettoken?devicename=iPhone+5&appid=hueapp&deviceid=**BRIDGEID**
Right click on "BACK TO THE APP" and write down ACCESSTOKEN inside the link it redirect to
phhueapp://sdk/login/**ACCESSTOKEN**
Basically it is a hack to get your access token. You fake your app as the official iOS Hue App, and ask for access token that way. I am not sure there is an easier way out there, if you do know one, please do comment below.
You can potentially automate it by doing simulated log-in session and grab the the ACCESSTOKEN by scraping the page content. But I consider it highly unreliable because any change to the official page will likely break it.
I wrote this script that allows the automation of getting ACCESSTOKEN as of today, but I don't guarantee it will work tomorrow for the reason I explained above :P
Currently, this OAUTH process only works with official apps. There might be a slight chance that they will open it to other 3rd party apps.
Remote Control
Once authentication is done, this part can be done automatically. There are 2 known private endpoints for sending control command and getting all the status related to the hue bridge.
Sending Command Endpoint:
POST https://www.meethue.com/api/sendmessage
Getting Status Endpoint:
GET https://www.meethue.com/api/getbridge
Sending Command Endpoint
URL: https://www.meethue.com/api/sendmessage
Method: POST
URL Parameters:
token=**ACCESSTOKEN** (which you obtained earlier)
Request header
content-type=application/x-www-form-urlencoded
body
clipmessage={ bridgeId: "**BRIDGEID**", clipCommand: { url: "/api/0/**APIENDPOINT**", method: "**METHOD**", body: **JSONCOMMAND** } }
BRIDGEID is the same one you obtained earlier
APIENDPOINT the same as official API /api/<username>/*** by removing /api/<usename>/ part
METHOD PUT/GET/POST/DELETE the same 4 method as official API. Despite GET really doesn't work since all response from the Sending Command Endpoint is 200 explained in the following part, while DELETE is not tested
JSONCOMMAND The actual command body for example {"on":true}
Getting Status Endpoint
URL: https://www.meethue.com/api/getbridge
Method: GET
URL Parameters:
token=**ACCESSTOKEN**
bridgeid=**BRIDGEID**
Request header
content-type=application/x-www-form-urlencoded
Limitations
Current limitation is you cannot immediately know from the response whether your control command succeeded like the official API. All the response you get from calling the Sending Command Endpoint is pretty much always <200> if you are doing it correctly. But you can always pull all the status related to the Hue bridge from the Getting Status Endpoint.
Remote Control API
I wrote Philips HUE Remote API to specifically solve the remote control problem.
Enjoy :)
Paper
For full documentation please refer to this excellent paper:
Hacking Lightbulbs: Security Evaluation of the Philips Hue Personal Wireless Lighting System by Nitesh Dhanjani
I did some investigation by following the steps of #paul-jianer-shi however the access token are not shown in the generated HTML.
I think the Hue Portal has been updated and removed the way it potentially shows the access token.
I wrote a blog post about doing Remote Hue operations by reusing the access token of another application, like IFTTT. The main change is how to get your hands on that access token. The token in shown in the 'My Apps' section of the Hue Portal. Check the (De-activate) link. It contains the access token.
Next step will be to let Hue Portal trust my own app.
Philips plan to make the remote API available to 3rd parties(it's already used by IFTTT and meethue.com).
There is currently a form on the developer website to request an early access(must login):
http://www.developers.meethue.com/content/remote-api
Using WSO2 API Manager 1.3.1. Trying to use the API Manager to proxy to a REST service. I have set up the service in API Mgr and can successfully post and get responses, typically json, though some are text.
However, when I try to GET a resource that returns binary content (a zip "file", content-type:application/octet-stream), the API Manager does not seem to respond and I can see an error in the console window (i'm running wso2server.bat in console):
[2013-07-03 11:52:05,048] WARN - SourceHandler Connection time out
while writing the response: 173.21.1.22:1268->173.21.1.22:8280
I have an HTTPModule on my internal service and it seems to be responding with the appropriate content (I can see the GET and response data logged). I can also call to the internal service directly and get a response, so that end of things seems OK. But going through the API Manager seems to fail.
I found information on enabling other content-types:
WSO2 API Manager - Publishing API with non-XML response
http://wso2.com/library/articles/binary-relay-efficient-way-pass-both-xml-non-xml-content-through-apache-synapse
Using that information I tried to enable the application/octet-stream for messageFormatter and messageBuilder using the binary relay and it did not help (or seem to make a difference). I have even disabled all other content-types and use the binary relay for all content-types and it does not help.
Currently, I'm running with just the following in both axis2.xml and axis2_client.xml (in their appropriate sections):
<messageBuilder contentType=".*" class="org.wso2.carbon.relay.BinaryRelayBuilder"/
<messageFormatter contentType=".*" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
I still get my json and text responses, but WSO2 times out getting the zip content. I saw the JIRA referenced in axis2.xml about enabling the ".*" relay, but as the other requests seem to work, I'm not sure it's an issue for me. I did try adding
'format="rest"' to the API definition, but it seemed to break all operations even the ones that worked prior so I've pulled it back out.
Any ideas on what is happening or how to dig in and debug this will help. Thanks!
After working with this for much too long, it turns out that my WSO2 configuration was correct, using the Message Relay and BinaryRelayBuilder, etc. While my REST service could reply immediately, I was setting a HTTP header that I assume WSO2 does not like, because when i removed it WSO2 would reply at an expected rate (instantly).
I was setting the header:
Transfer-Encoding: binary
When I removed that header from my service reply, then WSO2 operated as expected. I don't know if that's a "bug" in WSO2 or if I was implementing incorrectly, but I do have what seems like a "workaround" by omitting that header from my service response.