heroku : Failed to fetch - heroku

I have a React front end application with a node back end.
When I run the application locally all works well, by that I mean I am able to post and receive data from my endpoint, when I deploy the code on Heroku I am not longer able to post to the back end.
It seems that Heroku doesn't include the back end node when publishing the application
P.s this my first post, so apologies if I didn't provide the right info off the bat.

Related

Incoming webhook URL gets auto-removed

I'm completely new to slack development and I might sound crazy here.
This is what I have noticed. Whenever I use my incoming webhook URL to test messages using postman, it works fine. BUT, when I use it in my app and push the code in github (so it deploys to heroku), the incoming webhook gets removed. Is this something expected and that I missed reading in the documentation?
Ok, got answer to this. Basically, got an email from slack explaining the reason.
We recently discovered a publicly accessible incoming webhook associated with the Journey Alert Bot app installed on your sync.slack.com workspace. This can happen when someone who created or has access to a webhook URL posts it on a public site, such as Github or other code-sharing forums. None of your data is at risk — webhooks can only send messages into Slack and cannot access any data.

Bot Framework dotnet Slack adapter fails to verify Slack request when changing the Events Request Url

I have a Slack bot that is working fine and interacting with users. I'm using Bot Framework composer and the Slack Adapter.
In the Slack API portal I'm trying to change the Events Request Url the app uses to send Slack Events to my bot.
When I do that, slack sends a challenge request to my bot. The bot first tries to verify that the request is really coming from Slack following: https://api.slack.com/authentication/verifying-requests-from-slack#a_recipe_for_security
The problem is that this is failing and I can't understand why.
I see that Slack is sending all the right content, and that the ClientSigningSecret is being read, otherwise the other calls to the bot wouldn't work.
I know it's a bit far fetched to ask this since it seems to be a problem on my side. But since the bot is validating the requests just fine when users talk to the bot, and the code is from the Slack Adapter which is open source and there's nothing else I can thing of..... maybe someone struggled with the same problem.
I created a support ticket to Slack and they came back pretty quickly.
Pre publish state
Before publishing a Slack app the only configs that exist are the ones you see in the App configuration page. Those are what you use to test your app, this includes the secrets to authenticate the incoming messages from Slack into your backend.
After you publish your Slack App for the first time
Once your app is published, the production version that your users use will see the original settings, including the secrets and these are the ones your backend will get.
The settings you see in the configuration page are like development mode and they won't be persisted into the published app until you request Slack to approve your changes. That's sounds great and is what one would expect, but what you don't see and have no way of imagining is happening is that there are some development time secrets that are different from the ones you see on the settings screen.
When you change the endpoint url to be sent to your backend so that it can return the challenge and Slack would accept the new url, the message payload goes with this development secret and not the one you configured your backend with. Thus your backend will reject the call since it thinks it's not coming from Slack.
Proposed solution from Slack
Don't validate the signature of the incoming request for this type of call in an already published app. I don't like it but there was no other workaround unless Slack changes this. So what I did was:
Remove that check only for this request from the backend and publish to production.
Make the url change in Slack.
Revert the change from the backend.
:(

Custom google home action should always reconnect to get it working

i have a custom google home action implemented as described in the documentation (Oauth2 setup, sync, execute, etc... setup) and all works as expected on my Google home app and my google home physical devices.
Now, every now and then i need to reconnect the app in the Google Home App because it seems the app cannot reach my devices after some time. I checked my Oauth server if the refresh tokens are working ok and they do. Also my access token expires after 20 minutes and me reconnecting to the app should be done after some hours so the refreshing works in my opinion.
Now, are there any restrictions in using the TEST of the google home action?
The case i wrote is specific for personal use (intergration with personal server and domotica system) so i am actually not planning on releasing it, I just want to use it for myself. Is this allowed? Can i just leave my action in 'test' forever for such purposes?
EDIT: 18/05/2022: custom actions still working flawlessly after 6 months in test :-)
EDIT: 02/02/2023: custom actions still working flawlessly in test :-)
Additional question:
If i have to submit the app for release, i cannot meet the expectation in implementing state report as i have no control over the usage of buttons pressed at my home domotica. Is State Reporting also accepted when i report the state of my devices over time (let's say, every hour?)
tnx
EDIT:
So it seems there is something wrong with my refreshing of the tokens but i don't know what. When i try through postman, all works as expected, in stackdriver logs i see this :
jsonPayload: {
#type: "type.googleapis.com/google.identity.accountlinking.type.AccountLinkingError"
errorReason: "Failed to get response from 3P. 3P returned malformed response like invalid response code or un-inflatble body."
request: {
body: "grant_type=refresh_token&refresh_token=REDACTED_VALUE&client_id=qbusauth&client_secret=REDACTED_VALUE"
method: "POST"
uri: "https://******.azurewebsites.net/token"
}
sessionId: -1039956344
step: "REFRESH_ACCESS_TOKEN"
If you don't plan to submit your Action for release, you'll just need to occasionally re-enable device testing through the console.
To minimize the number of query intents to your fulfillment, you should implement Report State and proactively send device states to update HomeGraph. You would have to implement this if you decide to release your Action.

How to asynchronously push data to reactJs from Spring api web service to update a progress Bar?

I have an application which allow an user to send a lot of SMS to his contacts (like thousands).
Obviously that tasks can take a lot of time to complete.
So the idea is to display a progress bar on the client side, to indicate the user how many messages have been sent so far.
The back end of my app is a restful spring webservice.
The front end is done with ReactJS and Redux.
The question is:
Is it technically possible from the back end to periodically push data to the client, to update the progress bar, with the amount of messages already sent.
First question regarding the back end architecture:
I've seen that using JAX-RS 2 with spring, I can make asynchronous call in the back end, to execute other tasks(like querying the DB to see the messages already sent) while the other process is sending all messages. Am i looking in the right direction here ?
Second question regarding front end :
So far I use thunk functions for my requests(post/get) to the server, which returns a json response, and it works well. But in this case, the back end would periodically push data to the client side, until the main task is completed, so I don't understand how would that work out exactly ?
I guess I'm not gonna be able to achieve that using the same request ? Should I look at other technologies to achieve that ?
Please let me know, if the description of my problem is not clear.
Cheers
There are two options: you can keep track of the task on the backend and have an API endpoint to check the status and poll it every x seconds.
The other option would be to use sockets, the frontend client would listen for an event and update display onEvent. The backend would be responsible for emitting events.

Was this a successful Google Actions API call on Heroku

Im following the Number Genie article here:
https://developers.google.com/actions/develop/apiai/tutorials/number-genie
Ive taken the files and put them in a github repository here:
http://github.com/quique123/mygennie
I got this in the Heroku log:
body:
{"originalRequest":{"source":"google","data":{"surface":{"capabilities":[{"name":"actions.capability.AUDIO_OUTPUT"}]},"inputs":[{"arguments":[{"raw_text":"36","text_value":"36","name":"text"}],"intent":"assistant.intent.action.TEXT","raw_inputs":[{"query":"36","input_type":2,"annotation_sets":[]}]}],"user":{"user_id":"sometring/mIqGRE=","permissions":[]},"device":{"locale":"en-US"},"is_in_sandbox":true,"conversation":{"conversation_token":"[]","conversation_id":"1493419815932","type":2}}},"id":"e5ca3d68-3efa-4285-923f-3e1ff7fz87cf","timestamp":"2017-04-28T22:33:51.422Z","lang":"en","result":{"source":"agent","resolvedQuery":"36","speech":"","action":"check_guess","actionIncomplete":false,"parameters":{"check_guess":"36"},"contexts":[{"name":"actions_capability_audio_output","parameters":{"check_guess.original":"36","check_guess":"36"},"lifespan":0}],"metadata":{"intentId":"c863e1e2-c950-45d8-9b96-b57e0b1de77e","webhookUsed":"true","webhookForSlotFillingUsed":"false","intentName":"provide_guess"},"fulfillment":{"speech":"","messages":[{"type":0,"speech":""}]},"score":1},"status":{"code":200,"errorType":"success"},"sessionId":"1493418215932"}
But the web simulator returned a sorry, that is not available right now when I tried to guess a number. Why does the json payload hace a code 200:success then?
How quickly are you getting the message that it isn't available? The Google Assistant on your home will timeout requests after about 5 seconds. If your server doesn't reply within that time, Home assumes there is a problem with the connection and terminates the session. It is possible that your application took longer than that to run, so it generates the message about being unable to handle it at the moment and, some time later, your function finally returns results.

Resources