I'm new to this API, node fun stuff.
I just setup my node application for a school project and hooked it to a domain. Already it's showing some weird spam GET commands, should I be worried? Is it the server that is getting redirected to those spam sites?
Image to explain:
https://i.gyazo.com/a21b0acf9e3749f7ebabb2d1e6fed4d6.png
- Do not enter the link from the console.
Are these logs being created by your server code? I'm assuming they are, in which case, it is showing the requests being made to the server, the request method (GET,POST,PUT,etc.), and response codes per request that were sent from your server back to the requester.
I'm also assuming these logs are coming from your server code thats deployed on a machine and hooked up to your domain name, in which case, it means that requests were made at
{your_domain_name}/assets/title.png (http status code - 200)
{your_domain_name}/status (http status code - 200)
{your_domain_name}/w00tw00t.at.ISC.SANS.DFind: (http status code - 200)
/assets/title.png, /status, /w00tw00t.at.ISC.SANS.DFind: are all called paths and are the destination at which a requester would communicate with your server. Your server code should expose "endpoints" that requesters can interact with - often a SOAP or REST API.
If I've made too many assumptions or you have more questions I'll be happy to adjust or add input.
Related
I just deployed an application into cloud run, but the application running in cloud run can't handle the request in the form of POST method and always returns 404 not found. After I checked the log, whatever request was given it was always translated into the get method. What should I do to prevent the given method from being translated like that?
the log:
Notice the HTTP 302 response on your POST. That means the client is being instructed to go to a new Location. Your client is then converting the POST into a GET and making another request at the new location.
Cloud Run only supports HTTPS. Your POST request is being sent to an HTTP endpoint. The Cloud Run frontend will automatically redirect the client to the HTTPS endpoint.
Change your request from using HTTP to HTTPS.
I would like to build an integration using the Acumatica REST API. However, before logging in or anything. I would like to know if there is a way to test that the server is up and running.
I've tried logging in and I looked at the swagger.json to look at all the endpoints but I think they require to be logged in.
I would expect a 200 response when the server is up and a 500 when the server is not. 5XX if there is server issues and an error if it is completely down.
There is no Test function that I know of. I would recommend doing a HTTP GET request on the endpoint URL. If the request succeeds it will return the WSDL schema with 200 success code.
Azure gives a URL of the App Service when an App Service is created in it. I use a URL Ping test (a feature provided by App Insights) in Azure to test the availability of my Mobile App Service. I ping the URL of the app service and check for a 200 HTTP response. If I receive 200 response, I decide that the test has passed. However, recently I noticed that the URL was giving me a 200 response, but the site gave me a message saying 'Critical service is unhealthy'.
This was a problem for me because I thought 200 was synonymous with 'everything being OK'. I want to know whether the URL will always give a 200 response and it is only the text message appearing on the site which will say whether the app service is running fine, unhealthy or down. If not, what are the different cases in which the URL responds with 200 HTTP code?
EDIT:
I think I couldn't clearly communicate my need in the question. I will try to do that now. The fact that I need to go through the diagnostic logs to debug the issue with my mobile service is clear to me and I am not asking for help on that front.
I am using the URL Ping Test to test the outside-in availability of the mobile service (synthetic availability check). Now, I check for the HTTP response 200 and deduce that the mobile app service is available. Now, that I have discovered that 200 is sent even when the app service is unhealthy, I need to modify my test. How can I do that to ensure that my availability test fails in such scenarios?
Additionally, the following is the webpage of the app service URL when all is fine. This webpage gives a 200 HTTP response.
Now, is there a place where all the different webpage display of the app service URLs and the corresponding HTTP response codes are compiled?
A "URL Ping Test" is more than just a test for 200 - it will also (optionally) try to download all the images and files, do content matching, and retry if a failure is encountered.
Firstly, make sure you have a home page. The home page can be turned off - that is dependent on your site. Also, as #Alex suggested, turn on diagnostic logs and see what the error is produced. Use Postman to send a request to the home page and see what you get back.
Now, got the idea, i think. For being able to do what you want, i would offer you to customize a little your URL web test as described here. If your web app returns 200 OK, and you suspect that there is something wrong, use the payload of the response. For example, if the payload of the response is not equal to "everything is OK", even if that is 200 OK the test should fail. I think that for now it is the only one way to implement that using URL tests from Appinsights.
I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization
I get this question a lot =/
But I only know how to answer it at a very high level.
From the minute a user enters a URL and hits enter, what happens on the client and server side, and how do requests/responses work? How does the server interact with CGI/interpreters?
It would be helpful too if you could direct me to a URL that has this information in detail, or if you can answer it.
When I describe this to people I always feel like theyre looking for specifics and I'm not giving enough detail.
Thanks!
Client initiates communication (Usually a HTTP GET request)
Server receives REQUEST-HEADER and parses the URL contained within.
Server does a lookup to see if any URL matches locally in a harddrive-folder. If the webserver handles virtual servers like a Microsoft IIS, then it will determin which folder to search after retrieving the "www.domain.com" part from the REQUEST header.
If web-document (HTML file) is found, then Server sends this back as RESPONSE + a HTTP status code (eg. 200 saying: found, this request went well, where as 404 is "didnt find that file")
Client (browser) receives RESPONSE and can now display it as it wants. If it contains a render engine, then it will search for patterns (HTML tags or whatever language) and then display it as such.
This is also called "stateless" as the server closes communication with client after the client has received everything from the reponse-stream.
Therefore the server cannot know if the client is still connected nor if its comming back later. Many servers does provide a session object using cookies or similar to track if its the same client that sends the next REQUEST and if so, allowing more "intelligent" server responses - such as seeking, transactions and logins.
How does the internet work?
HTTP Made Really Easy
The Canonical Document: RFC 2616
The client sends request headers to the server (finds the IP via DNS).
The server software (e.g. Apache) calls CGI if it needs to and prepares the response.
It sends headers back as well as the content.