sls alexa auth returns 400 Bad Request - alexa

I have recently started working on alexa serverless. I have followed the steps as mentioned in a serverless blog https://serverless.com/blog/how-to-manage-your-alexa-skills-with-serverless/
I have installed the serverless and created security profile and updated the Web settings with allowed return url i.e, https 127.0.0.1:9090
After this I ran the command sls alexa auth. From here I am getting error like this
I am unable to find whats happening behind the screens. whats with code. Required environment variables are set.Can somebody help me

Go to Amazon Developer Portal. Choose Login With Amazon > Security Profiles > Edit > Web Settings.
Make sure you have the Allowed URL field filled in with your IP.

I had a similar issue. I updated my Allowed Origin and Allowed Return URLS to the following and it worked. Here is a screenshot.
Link:
https://developer.amazon.com/settings/console/securityprofile/web-settings/update.html

Related

Salesforce DocuSign API Sync Issue

New to the forum :) - first post. I am trying to set up DocuSign in Salesforce for a client and keep running into an issue when trying to create an envelope template. Some context: my client has a DocuSign Business account (not Gen/ Negotiate), I have added the documents, and can add non-merge fields fine. The only issue is when I try to place the merge field, not create it, I receive an error:
Save Error: Some fields might be out of sync. Unable to connect to the service. Failed to connect to the salesforce service.
So far I have tried: adding IP addresses to Salesforce, removed MFA authentication for API, I have tried clearing cache and cookies, in different browsers, and in incognito mode - no success. I think I just have missed a step in set up? OR is this just not a feature of the client's current account and they need to enable the "Gen" feature to use merge fields?
Appreciate the help - I am also new to Salesforce administration and coding - so I am learning as I go and bear with me if I am not picking up all the "lingo" up front.
It sounds like you're using the legacy DocuSign for Salesforce package if you're not using Gen/Negotiate, so there are typically a couple of issues that could cause the error that you're seeing. The first is a caching issue, so you could try in an incognito browser or by clearing cache and cookies for the browser.
The other issue could be that the connection between DocuSign and Salesforce was broken and needs to be connected again. If that's the case, you could follow the steps in this article. If you're still running into problems, I'd advise to reach out to the DocuSign support team so that they can take a look with you (https://support.docusign.com/).

Trying to implement in-app voice call from browser

I have cloned the click-to-call repository and followed the steps as mentioned. I am able to login with said created user but then get stuck at /rtc API.I got some error in network panel. and "General SSL engine problem in console which is not correct. SSL certificates are all correct." Let me know where i went wrong. Please check the screenshot below :
I have had a talk with nexmo team, they said it is the ssl issue.
https://help.nexmo.com/hc/en-us/articles/207051767-Certificate-for-nexmo-com
Now I am unable to find where to import the certificate to my app?
I am the JavaScript Developer Advocate at Vonage (Nexmo).
You also filed an issue at https://github.com/nexmo-community/client-sdk-click-to-call correct? Thanks for that. I will also post my response here.
From your issue, it looks as if the Conversation Id is not being sent.
We recently merged some changes to the repo.
In your .env file, do you have SUPPORT_PHONE_NUMBER? That should be NEXMO_NUMBER.
Also, when calling the server, previously the code in the client.js around line 34 was application.callServer(); it is now application.callServer(application.me.name);
Let me know if this works for you.
Check with Nexmo - either you are out of balance or your account has been been marked inactive for some reason. Most of the time its because of insufficient balance.

AppEngine authentication through Node.js

I'm trying to write a VSCode extension where users could log into Google AppEngine with a google account, and I need to get their SACSID cookie to make appengine requests.
So I'm opening a browser window at
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttp://localhost:3000/
(generated by google.appengine.api.users.create_login_url)
The user logs in and is redirected to my local webserver at
localhost:3000/_ah/conflogin/?state={state}
Now I try to forward the request to my AppEngine app (since it knows how to decode the state parameter), so I do a request to
https://my-app.appspot.com/_ah/conflogin/?state={state}
basically just replacing localhost with the actual app.
but it doesn't work, presumably because the domain is different. I assume this is on purpose, for security.
Is there any way I can make this work ?
Not ideal, but the only solution I've found is to have an endpoint on my GAE instance that does the redirection. Then I can set that as the continue url, when I'm starting the authentication process
https://accounts.google.com/ServiceLogin?service=ah&passive=true&continue=https://appengine.google.com/_ah/conflogin%3Fcontinue%3Dhttps://my-app.appspot.com/redirect?to=http://localhost:3000
I think you should center the attention on the protocols you are using, since it’s known that the cookie name is based on the http protocol (HTTP : ACSID, HTTPS:SACSID), and that’s the security perspective till this point for me.
Having the error you are facing now would be helpful to understand the problem better. Also, how are you performing the call to the API and the code you are using would be helpful too.

Having issues getting WordPress running under GAE + Cloud SQL

I tried to set up WordPress under Google App Engine earlier tonight (following the instructions here: https://developers.google.com/appengine/articles/wordpress).
It runs fine locally, but when I push to remote I get a database error (visible at https://wp-dot-frontiermediag.appspot.com/). If we throw on a /wp_admin/install.php you get:
This either means that the username and password information in your
wp-config.php file is incorrect or we can't contact the database server
at :/cloudsql/frontiermediag:fmwp. This could mean your host's database
server is down.
Here's the relevant code in wp-config:
/** MySQL hostname */
if(isset($_SERVER['SERVER_SOFTWARE']) && strpos($_SERVER['SERVER_SOFTWARE'],'Google App Engine') !== false) {
define('DB_HOST', ':/cloudsql/frontiermediag:fmwp');
}else{
define('DB_HOST', 'localhost');
}
frontiermediag:fmwp is showing "Status Runnable" in Developers Console > Cloud SQL.
I did this once before and it worked so I'm not sure what I'm missing here. I thought it might have been because I'm using WP 3.8.1. but rolled back to 3.5.1 and same thing's happening.
Any ideas? frontiermediag is listed as an authorized application on the :fmwp ACL.
This situation happened to me earlier.However, I edited my Cloud SQL instance , and set "Preferred Location" as "Follow App Engine App" from Google Developers Console. This database connection problem was solved in my case.
I tried the instructions with wordpress 3.5.1 and the instructions seem to work for me. The code snippet you have above seems right and I am not sure what could be wrong without looking at rest of your code. Can you try the instructions from the beginning one more time with 3.5.1?
I had this issue, because "Follow App Engine App" doesn't seem to be an option for second generation instances in my case, and so the instance connection name includes the region setting.
Look at the instance details, and under properties, find "Instance connection name". That is the text that should follow :cloudsql/.

302 status when copying data to another app in AppEngine

I'm trying to use the "Copy to another app" feature of AppEngine and keep getting an error:
Fetch to http://datastore-admin.moo.appspot.com/_ah/remote_api failed with status 302
This is for a Java app but I followed the instructions on setting up a default Python runtime.
I'm 95% sure it's an authentication issue and the call to remote_api is redirecting to the Google login page. Both apps use Google Apps as the authentication mechanism. I've also tried copying to and from a third app we have which uses Google Accounts for authentication.
Notes:
The user account I log in with is an Owner on all three apps. It's a Google Apps account (if that wasn't obvious).
I have a gmail account this is an Owner on all three apps as well. When I log in to the admin console with it, I don't see the datastore admin console at all when I click it.
I'm able to use the remote_api just fine from the command-line after I enter my details
Tried with both the Python remote_api built-in and the Java one.
I've found similar questions/blog posts about this, one of which required logging in from a browser, then manually submitting the ACSID cookie you get after that's done. Can't do that here, obviously.
OK, I think I got this working.
I'll refer to the two appIDs as "source" and "dest".
To enable datastore admin (as you know) you need to upload a Python project with the app.yaml and appengine_config.py files as described in the docs.
Either I misread the docs or there is an error. The "appID" inthe .yaml should be the app ID you are uploading to to enable DS admin.
The other appID in the appengine_config file, specifically this line:
remoteapi_CUSTOM_ENVIRONMENT_AUTHENTICATION = (
'HTTP_X_APPENGINE_INBOUND_APPID', ['appID'])
Should be the appID of the "source", ID the app id of where the data is coming from in the DS copy operation.
I think this line is what allows the source appID to be authenticated as having permissions to write to the "dest" app ID.
So, I changed that .py, uploaded again to my "dest" app ID. To be sure I made this dummy python app as default and left it as that.
Then on the source app ID I tried the DS copy again, and all the copy jobs were kicked off OK - so it seems to have fixed it.

Resources