I'm studying node.js and trying to implement the following task:
I have to get connection to existing https - for this purpose I decided to choose needle module:
needle.post('https://...', data, options, function (err, res, body){ });
I need to send a request to server as json object using these parameters:
{"action": "AuthenticationManagement", "method":"login", "data": [null, null], "type": "rpc", "tid": 1}
As I understand it, these parameters should be sent in terms of data within needle.post.
In case I have connected to the server, I need to get cookies from it (sessionID parameter, etc) and save it to file/keep it in memory
during my further operations with server. Looks like, cookies should be sent back in res.headers.
Properly end the session.
Any help will be much appreciated.
Needle does not support cookies yet. I 'd suggest using a different library rather than rolling your own implementation over needle.
Related
I'm migrating from Firebase where this was rather simple to do.
I'm building a custom api because the environment I need to build in will not let me use any official sdk's or anything, so this solely has to be done via rest type actions.
I essentially want to just post the username/password to aws cognito, and recieve an auth token that I can then append to the headers of future requests (to other api calls)
After hunting for quite a bit, almost all help has postman connecting to Amazon's login UI etc, and I cannot do that. It must completely handle the login process "behind the scenes" and not prompt the user with Amazon's own UI.
So, assuming this is possible:
What headers do I need (content-type etc)
How do I format the body json (or is it using something else?)
I assume I'd send it as "raw" body.
This is as far as I got so far and I'm scratching my head:
Url: https://[DOMAIN].auth.us-east-1.amazoncognito.com/oauth2/token
Body Json:
{
"ClientId": "1234etc",
"Password": "Password1_",
"UserAttributes": [
{
"Name": "email",
"Value": "test#test.com"
}
],
"Username": "test#test.com"
}
No idea if this is even the right format for the JSON I just scalped it from other posts.
I'm using websocket for real-time communication for my mobile app project. I implemented basic security logic:
To connect to the server, the client must have a key,
-when the client connects to the server it sends immediately a JSON object containing authentication information
{
action:"auth",
device_id: "string",
auth_key: "string",
user: "string"
}
-The server replies with a session id if the key is correct, or drops the connection
- From that, every data sent by the client, will be JSON object having that session id, so that the server, can recognize it, all unknown clients are dropped.
Now the big problem is that, WebSocket protocol doesn't understant JSON, so i have to use JSON.stringify() and JSON.parse() to send my data through, also i have to check if the session id is valid this takes time and the application is not smooth anymore(before it was).
For example, if it records mouse pointer moves, such data will be sent to the server as the mouse is moving, so it sends data several times in short period ,
and because the logic i've implemented, it's not smooth at all
{
session_id: "string",
user: "string"
action:"mousemove",
position: {
x: int,
y: int
}
}
My concerns are:
-Secure the server, so that no one can access it and send commands, without authorization.
-Keep it REALLY real-time
-Have a good data format (as JSON if possible)
To really make your communication secure, you need to use TLS connection.
Stuff you are doing with users authentication looks ok.
But it's strange that authentication time is a problem for you, probably you need to implement session cache, to make session id validation quicker.
JSON isn't best format for network data transferring from size perspective, but WebSocket specification doesn't specify formats, it's up to you what to use, and JSON is also ok, unless you are really concerned about traffic savings.
To make your communication smooth, you can aggregate data on client side, and send this data once per second for example. I believe you don't need so much mouse coordinates actually.
I'm adding a new REST service to our API, and wanted to canvas a few opinions on the best REST API. The service is used to retrieve the user's email address in case they have forgotten what their username is. The service requires three parameters:
Account number (this is a number that is on their printed statement)
Surname
Date of birth
If we find a match for these three pieces of info, the service returns JSON contained a masked version of the user's registered email address (eg. jo******#gmail.com) so that the UI can present a message something like "We are going to send your username to j******#g******.com. Is that OK?"
Note that the service doesn't actually change anything within their account or send an email (it is purely fetching info so that the user can confirm the next step), so it seems to me that a GET request is the way to go. The question is how to represent it? It strikes me that /users is a reasonable place to start(?), but then what? Using the URL path, I might end up with something like:
/users/accountEmail/accountNumber/123456/surname/Smith/dateOfBirth/25-12-1970
This seems icky as, ordinarily, our /users URLs contain the username (eg. /users/john/transactions), but clearly for this API call we don't actually know who the user is yet. I'm also not sure it really indicates what the service actually does. Alternatively, I could use URL query params:
/users/accountEmail?accountNumber=123456&surname=Smith&dateOfBirth=25-12-1970
This feels a bit more natural, but I'm unsure that stringing all those input parameters into the URL is a good idea. Then again, maybe /users is the wrong noun. Maybe it should be like:
/accountEmail/...
Having said all that, maybe given the service's idempotence, I could actually use a PUT request and encode the parameters into the HTTP body. Not sure about using PUT for read-only requests though... it seems a bit like heading down the RPC path. The one nice thing about the PUT approach though is that it doesn't log this relatively sensitive user input into any web server logs.
I'd be interested in opinions or hearing what other API developers did in a similar situation. Thanks.
First of all, don't use method GET with sensitive information in URL parameters or in a URL path, because that information can be stored in web server access log files, browser's history, HTTP proxy log files, etc.
Security wise you need to use method POST in this case. In regard of URL to use, I'm not that sure, probably something like /accounts and put all parameters to the request body.
Your second approach is what I would use. Logically, the URLS are build following these steps.
Collection Resource of Users
The URL
GET /users
returns a list of all users including all user properties.
[
12345: {
"surname": "Smith",
"firstname": "John",
"dateOfBirth": "1970-12-25",
"accountEmail": "john.smith#example.com"
},
6789 : {
"surname": "Hallow",
"firstname": "Jane",
"dateOfBirth": "1981-02-15",
"accountEmail": "jane.hallowh#example.com"
}
]
Sub-Collection Resource of User Emails
The URL
GET /users/accountEmail
returns al list alf all emails for all users.
[
12345: {
"accountEmail": "john.smith#example.com"
},
"accountEmail": "jane.hallowh#example.com"
}
]
Filter this Resource
The URL
GET /users/accountEmail?accountNumber=123456&surname=Smith&dateOfBirth=25-12-1970
returns a filtered list of emails for the users that match the query parameters.
[
12345: {
"accountEmail": "john.smith#example.com"
}
]
New here. I've searched quite a bit for a working solution to my problem, but even though I have found posts with promising titles, none of the solutions have worked.
I am deploying an MVC2 web app to a client's server.
I did my development on Win2k8 Server, but they are running Win2k3 sever.
The app's only purpose is to receive some record ID information as HTTP parameters, check in the database for the status of the given record or records, and then return the status information as a simple string such as "Completed" or "Incomplete" in JSON format.
This getJSON code works fine in the development environment.
Inexplicably to me, on the client's server, the getJSON request receives a null response from the application.
There is no cross-domain action AFAIK... the result is the same from the client's server or from my machine via VPN.
In the MVC model's Json code, a common solution for people is to add the "JsonRequestBehavior.AllowGet" attribute to the Json result being returned. I did this long before trying to deploy it, and as I said, it has worked fine in the dev environment.
Using Firebug, I have watched the same request URL get sent to both my local server and the client server - the response headers from both servers are the same, but the response content from my server is shown as:
{"Result":"No Data"}
Which is what I want.
There is literally no content shown in the response from the client's server..? But the request gets an HTTP 200 code and is recorded as a success in the reponse's status attribute.
The response header content type in both situations is "application/json"
But wait, there is more!
If I manually enter the request to each server in the Firefox nav bar, and hit enter, in both cases it responds with:
{"Result":"No Data"}
Which is what I want. So why can I get the result I want from the MVC app on the client's server only when I hand-enter the request URL in Firefox, but not from the Javascript code?
I have tried forcing different output content types ... using the jQuery ajaxSetup method...
$.ajaxSetup({
async: false,
dataType: 'text'
});
or
$.ajaxSetup({
async: false,
dataType: 'html'
});
and again wtih 'script', and 'json'. I also tried the conversion options such as 'text json' or 'html json' or 'json text' and so forth.
Some of the posts I'm reading, and my gut feeling, though, suggest the problem is not the jQuery code making the request that is at fault... I don't see how the same jQuery request point to a different server running the same app would suddenly cause that server to send back a 'null' value.
By null, I want to be clear... I mean nothing is sent. There is no {} or {null} or any sign of JSON... just blank whiteness of non-existence :P
Even if nobody knows the answer, I would love some input perhaps suggesting where I should focus my sleuthing ... client or server?
If the problem is the server, it seems hard to really know that the MVC stuff is running 100% on the IIS6 server, but in general it seems to work. I have a different MVC app running on the client server which responds to the virtual paths, and generally runs the same as on dev machine.
I have found one thing ... the request headers are somewhat different? The Request Headers sent to the IIS7 setup include an "X-Requested-With: XMLHttpRequest", "referrer" , and "cookie" field/value.
I could guess that the lack of the "X-requested-with: XMLHttpRequest" in the IIS6 request headers is a clue, but I do not see then how the same javascript code pointing at a different server can generate different request headers itself. So how else are those being generated?
The javascript is embedded in an ASP.NET page, btw.
Oooh.. frustration!
Thanks for any input.
Odd Progress ... apparently there is some sort of issue with IIS6 handling the query. Although I have not payed any attention to JSONP, a post elsewhere suggested that sometimes use the "&callback=?" parameter at the end of a .getJSON request URL would force it into GET mode and that worked frequently for problems getting data from the server. So I did that... and it did work, sort of. The proper {"Result":"No Data"} was returned in response to the request... which seems good. However, the way that the JSONP callback works, it generates its own script to do the calling and fetching and interpreting of the incoming JSON. In this case, it interprets the JSON to need a label which it does not have, thus an error is thrown "invalid label" ... there must be some way to hack things to just deliver the JSON, but the whole required use of JSONP callbacks suggests that the server configuration is wrong, right? Or why does it work without JSONP for IIS7 and not IIS6?
Despite my not liking the callback JSONP solution, it appears to work ok. The error is still returned about an invalid label, but that does not appear to stop the remaining javascript from running... and so the application is working with IIS6 now. I have not tested the fix of using the callbacks and JSONP against IIS7 yet, but I expect it will work well enough.
Here is a link to the discussion that lead me to my current solution. I do still hope to find a more elegant solution, however.
NeoWin.net
Are you certain that your App Extension Mappings are set up correct?
Follow this article for running MVC2 on IIS6 and ensure all the different configurations have been done, that's probably the first step before going further and investigating specifics.
I'm really inclined to believe it's related to HTTP Verbs.
Not a great title but I'm looking more for some guidance, have searched quite a bit. I'm building a web app with an MVC framework (but I think this is a more generic question). I'm trying to make many views that do a lot of AJAX style calls and say I have a site with users and they can add folders and files to their profile page. So the URL maybe like:
/profile/{id}
I have a Profile controller that returns a view with various information. I'd like files and folders listed on the profile to be dynamic so I want to populate it through AJAX calls. I was thinking I would have a URL like
/listFolders/{userId}
and
/listFiles/{folderId}
Is it reasonable to have these URLs return a JSON object for these two URLs and not even provide an HTML view (since, for the browser, the view will just be the whole profile page)? Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data? Is it reasonable to just set 404 or 403 HTTP error codes or do they need to return some kind of HTML? What if there are multiple reasons for it to fail and I'd like to pass that along? Should I arbitrarily choose HTTP error codes or define integer return codes like 0, 1, 2, etc? Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
I have used JSON in my previous projects. For errors, we return error codes.
We decided to do so because we were dealing with API clients. So we want to deal with error codes (REST is based on HTTP, so it was appropriate to return error codes).
Since you are writing your own application, you can pretty much choose how you want to send your errors to the view. You can create a error json object and in the view you have to check whether this object is not null.
pretty much a if-else in the view. Else you can return error codes and check for the code before rendering the JSON into whatever view you want to.
I would go with error codes, because that complies with the REST philosophy.
Generally speaking, I handle this situation by throwing a 500 internal server error with a status message. Most client libraries such as jQuery provide built in error handling with a failure callback like:
jQuery.ajax({
success:function(response){
//do some success stuff
},
error:function (xhr, ajaxOptions, thrownError){
//handle error
alert(xhr.responseText);
}
});
It's entirely feasible to return JSON objects as opposed to actual views.
As far as the url, you can use listFolders and listFiles without taking on the JSON. However, I recommend you use lower case urls for the sake of how the server is setup. For instance, I know on Apache that sometimes listFiles would be fine, but listfiles would lead to missing page exception.
With regards to errors: You could setup a header of sorts in your JSON response and use whatever system you'd like. For instance, you could do something like
status_code: 0 //where 0 means successful
status_detail:success!
Where, if the status_code is something other than 0, you'd check the status_detail and know to ignore everything else inside the response.
Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data?
These are basic HTTP Error codes:
401 : Unauthorized
404 : Not found
There's a whole slew of error messages in the HTTP spec:
HTTP Status Code Definitions
Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
Generally, a good way to handle this is for the client to set the 'accepts' header to something like 'text/json' or 'text/xml' and for the server to parse it out and respond with the correct response. This way you can use the same URL but send back different views of the data (if you ever wanted)