I'm simply trying to use Serverless and Lambda to make get and post requests to my Atlas cluster. I've followed all the tutorials below which are very similar:
https://hackernoon.com/building-a-serverless-rest-api-with-node-js-and-mongodb-2e0ed0638f47
https://dev.to/adnanrahic/a-crash-course-on-serverless-apis-with-express-and-mongodb-193k
https://dev.to/saigowthamr/build-and-deploy-a-rest-api--using-serverless-express-and-nodejs-3331
https://blog.eduonix.com/web-programming-tutorials/serverless-development-nodejs-aws-lambda/?unapproved=84149&moderation-hash=9ac99ba21b72d6be12fbb14c1005a540#comment-84149
Using Insomnia or Postman I can make get and post requests to a locally hosted database but not to an Atlas cluster. The requests always result in 502 Bad Gateway with JSON message of "internal server error". I've tried switch up the cluster host from AWS to Azure and that didn't help. In regard to the various drivers I've tried every variety of connection string. I've whitelisted all ips so access is not an issue. Please help.
I deleted the cluster, project, organization, and users in my Atlas account and started over. I didn't manually create a new user through the Network Access tab but rather created a user with the prompt you get when creating a Cluster. I noticed there was a note regarding special characters when making a connection:
When entering your password, make sure that any special characters are URL encoded.
My previous password used an # symbol which may have been causing problems. So be careful when using email addresses as user names. I assigned 0.0.0.0/0 to the user as usual. I don't think it matters but I only have one user and I added a comment to that user as well. Now I can make a connection using the 2.2.12 or later Node.js driver connection string. I hope this helps someone.
Related
I have a Google Cloud SQL PostgreSQL database in which I can connect by using SSL and by entering my IP address in allowed connection settings. However, I do not want to list all the IP addresses that is going to connect to this database (because I do not know all the IP addresses). I have around 15 people which I want them to login to my database using QGIS and they should be able to change the data as this is a research. Security is not a big issue as this database will be online for a very short period of time. What connection method can you suggest? The users are not very proficient so I need to setup everything.
I hope you're doing fine.
I would like to suggest to set the connections with the Cloud SQL proxy as it will provide the security needed without using ssl or the need of authorize any network. so basically the set up is to:
Enable the API
Install the proxy client on your local machine
Determine how you will authenticate the proxy
If required by your authentication method, create a service account
Also you can find the steps on "Connecting to Cloud SQL from external applications"
Hope this works for you as I have never used it with QGIS but I believe that as you are using a proxy it won't be hard from there to use it with QGIS as if you connected to a local server.
I have attempted this via many different methods and I do not see any issues with non-usgov related SoftLayer accounts. I have come to the conclusion after discussing this with a SoftLayer support person that the usgov SoftLayer accounts use a different domain when connecting. This support person recommended I create this ticket.
Typical Domain: api.softlayer.com
Usgov Domain: api.usgov.softlayer.com
I can only assume this is correct, as I can resolve the usgov domain via ping.
However I cannot reach it via typical means, example:
curl -X GET -u <USER>:<APIKEY> https://api.usgov.softlayer.com/rest/v3/SoftLayer_Account/getUsers
This instance returns:
curl: (35) SSL connect error
How can I resolve this issue?
try:
https://api.service.usgov.softlayer.com/rest/v3/SoftLayer_Account/getUsers
instead
https://api.usgov.softlayer.com/rest/v3/SoftLayer_Account/getUsers
Also keep om mind that in order to reach the server you need to use VPN, otherwise you never be able to reach it.
Regards
I have an issue with appears to occur randomly (however i suspect it occurs when starting up the application or changing the application settings). The error I'm getting is as follows:
An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80
The particular error in my case occurs when trying to generate a authentication token using Identity Framework by making requests to the following url:
https://domainname/api/token
Note that the api/token url is specified within the owin pipeline > OAuthAuthorizationServerOptions > TokenEndpointPath. This get set on startup of the application.
From my understanding 127.0.0.1:80 is azures localhost and is forbidden for us to access, i'm not sure why its defaulting to localhost as a domain, my educated guess is something is happening during the startup that's first setting the host to localhost.
My question is does anyone else get this on startup (while the site is warming up) for azure web apps?
Have i configured something incorrectly for me to be getting this behavior?
I know this is a little open ended but is there anything i can do to resolve this issue?
That is the well-known issue described in the official documentation. You may not to access not just a 127.0.0.1, but i suspect that the problem is even a little different - it looks like something is wrong with the :80 port usage. IIS use that port, and i would try to change the port used by your app.
However, from your description is not clear who is that guy who tries to do that - your app tries to do something with the 80 port, or the Azure WebApp functionality.
Please try to start from the eliminating the possibility of some renewing events by enabling Always On in the Azure Web App setting. It will make your web app always on, and will help to understand if that is caused by the service.
I have a php script that run perfectly when requested by the browser (example):
http://www.kwiksher.com/k3Serial.php?key="XXXXX"
in this case, I get the information of an user with the key XXXXX, which is the expected behavior.
However, inside my Photoshop plugin, I must to call it via socket, having to force a port in the connection:
http://www.kwiksher.com:80/k3Serial.php?key="XXXXX"
Doing that, I get the the content of Azure default 404 page (it is not even my customized 404 page).
If I use the same call (with the port added to the domain) on a browser, it works fine as well.
Any idea on how to fix it? I tried to flushDNS on my machine as well without success.
Thanks a lot,
Alex
It's likely that the socket library won't be using HTTP and therefore isn't sending a host header and the web tier on Azure can't actually figure out which Website it should serve the content from.
As you using this with a plug-in perhaps try and use the default hostname issued by Azure instead of a custom domain.
I've followed the guide:
Getting Started with Authentication with Mobile Services .NET for Windows Store
I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?
I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)
** Update 2014-03-20 **
Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.
With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.
I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:
The Response property is not helpful. It does not provide any additional information about the problem.
The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).
** Update #2 2014-03-20 **
After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:
"An existing connection was forcibly closed by the remote host"
The error code is 10054 (WSAECONNRESET) Connection reset by peer.
It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...
At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).
We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").
One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.
Henrik
Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.
You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.