We all know that GET method is to retrive information from the server while the POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource, for example, update a table. However, can we do update in a GET method??
Depending on the implementation language (availability of DB library) and access rights to the database, you can do anything you like in a GET request. Retrieving in GET and updating with POST requests is just an agreement and usually not enforced by the webserver.
Related
I have to create a middleware API which a functionality to check for a key present in my database. If the key exists then it should simply fetch it(GET method). If not, then the API should create the key and its value in the database and return that(POST method). So since we have 2 fundamentally different methods being combined in this API, is it correct to do so? What should be the best way to design such API?
Don't combine them.
Return zero results from your GET method if you the record doesn't exist. Then in the client, if you receive zero results, POST the needed information to another API endpoint.
Combining the two ideas into one will create a hard to understand system. Your system should be deterministic, i.e. you can always know the result of every call before you call it.
One way to look at your API is to forget about the underlying database, but think about how an API client uses it.
If an API client does a GET request, 2 things happen:
The existing record is returned
A new record is created and is returned
A client might not actually care if 1 or 2 happened. For the perspective of the client, it might look like the resource always existed (even if it was technically just created).
So as long as there's no extra information that must be sent along with a POST request, it might be fine to use a GET request for both cases.
I don't know about your situation, typically it is best to have your get and post seperated. Though, if your client thinks that it needs to create a record and then posts the data, i dont see the problem with returning the resource and a 409 for the resource already existing. Here is a similar question HTTP response code for POST when resource already exists
Then the client can handle the 409 differently or the same as a 200 depending on your needs.
Which is safer in term of security, sending parameters thru url or JSON object?
URL:
www.mywebsite.com/search.php?password=t45vye45vh
JSON object:
request.post(url, data);
The GET method requests a representation of the specified resource.
Requests using GET should only retrieve data and should have no other
effect.
Whenever user want to data from server using only basic details like userId or some other id then use get request.
POST submits data to be processed (e.g., from an HTML form) to the
identified resource. The data is included in the body of the request.
This may result in the creation of a new resource or the updates of
existing resources or both.
Post method generally used for form or passing more number of data to server. Whenever something needs to store on server, post request is used. Eg. for registration, login, file upload, making new record etc.
It depends what you are trying to secure against. For information assurance and maintaining an accurate audit history the URL is easier to capture in logs than the body of a request. It is also simpler to parse in a WAF.
To protect against abuse of this information then you might want to make it less obvious. Anyone reading the standard webserver log that uses your first example will be able to see passwords. Your browser will also retain this value in its history and users can create bookmarks containing passwords - neither provides a secure method of storage.
For anything sensitive use POST.
With HTTPS enabled, it is true that query string parameters are encrypted and cannot easily be sniffed. However, GET requests are stored in browser history, and proxy and server logs by default. They can also be leaked in the referer header.
POST requests are unlikely to be logged, and do not have the referer issue.
I am storing additional attributes in my '_users' db records. In the case where I have multiple users sharing a database, where one is the owner and one is the reader/writer, I would like to get that user's db property to see what database they have permissions to write to.
Is it possible to modify the response of POST _session or GET _session to respond with the cookie, but also with the db property from a '_users' record in the response body? Thanks in advance.
No, that is not possible at this time. This idea has been proposed, but not implemented a few reasons. (it's a long thread, but I felt it was relevant)
It sounds like you may want to take advantage of the database security object. This configuration allows you to set up specific users or roles with read/write capabilities per-database. (plus, this object will be sent to validation function, and it allows custom fields in addition to the mandatory ones)
I would like to implement a fine-grained authorization in a Neo4j Database accessed using the default Neo4J REST API.
The business data and the authorization rules will be persisted in the same Graph Database. Every node will have an incoming relationship "CAN_ACCESS" from other nodes representing the application users.
I would like to implement some kind of interceptor having the following behavior, on GET requests:
Read the authorization header
Perform the get normally
Based on the nodes to be returned, check if the user in authorization header has a "CAN_ACCESS" relationship to the retrieved nodes. If the answer is no, then change the response code to 401.
Is there a class in Neo4j Server API I can extend to plug this algorithm into my server? I think I need a single place to handle the request, the response and the retrieved data.
Perhaps you can look into overriding the RepresentationFormat for nodes and check in there.
You probably have to register a custom content type for this to work.
Another option is to add a filter to the Neo4j server and re-parse the responses and check there for your security rules.
Perhaps the filter used in the authentication extension can help you as an example:
https://github.com/neo4j-contrib/authentication-extension/tree/2.0
You can implement a SecurityRule for this. A SecurityRule is a filter that any request to the server needs to pass.
We currently have sessions disabled.
Instead, each request is sent with an access_token so that at the end of the request, nothing persists to the next request.
ie. Request received --> Validate access_token and set associated user as "current user"
The first issue we came across was the ability to access this use throughout the application.
eg. We need current user id in the repository
Our solution was to use node.js' domain. This didn't work out so well because when concurrent requests happened from different users the domain would be overwritted -- it was shared.
What I need is:
A globally accessible (or by require) object that can contain a
couple parameters I assign to it.
This globally accessible object to be unique for each request so that any given request could retrieve the information pertaining to itself.
Any suggestions?
The simplest way is to just attach it to your request object (do it in some middleware if you're using express).
req.access_token = 'get_the_token_and_put_it_here';
Now it's accessible from everywhere you can access your request object.