We use POST requests when changing resources and GET when searching for resources on the server right ? I want to know exactly what do we mean with 'resources' ? is it only the data stored on the database ? Can we consider the SESSION as one of these resources ?
Let's say I'm working on a PHP server and want to modify a variable inside a session, or destroying the session for the client, without modifying anything in the database. Should i use a POST type request or a GET type request for that ?
The HTTP methods can exist without a database behind. This names GET, POST, ..., are made for the understanding of the client. So, if the method creates, modifies, or deletes something, use POST, PUT, or DELETE (respectively) to let the client know that something is being created, modified or deleted.
Application State vs Resource State
Application state is server-side data which servers store to identify incoming client requests, their previous interaction details, and current context information.
Resource state is the current state of a resource on a server at any point of time and it has nothing to do with the interaction between client and server.It is what you get as a response from the server as API response. You refer to it as resource representation.
From: https://restfulapi.net/statelessness/
As For which method to use for changing Application State(session):
GET Request Should be idempotent so we cannot update/create the session with GET method.
Use GET to Get Value of Session, POST to update session, PUT to create session and Delete to delete session
Related
I'm using Laravel 5.3.
Essentially, when a user clicks a button on the screen, I need to get data from the database (using AJAX), and then display that data on the screen.
However, I'm not sure if I should be using a GET or POST request? I've only ever used GET requests for routing when the user wants to get to a specific page, like a GET request for /index or /profile.
Which should I use?
There is a difference between GET & POST method in Laravel
GET is used when we want to get some data from the server and we do not send any parameter in request. And the security threat is not a concern, like you are opening a page on browser
POST is used when we want to send some parameter to the server and based on that parameter some processing is done. In laravel it is mandatory to include CSRF token wit the request for security concern.
So choose as per your requirement.
easy! Use GET when you're to getting data, and POST when you're posting data.
There are even more of these request methods (or verbs, if you like). For example a PUT request to edit data, DELETE request to delete data etc. However, these aren't supported in most browsers yet, but i know laravel has a clever workaround so you can use them anyway. check this links:
https://laravel.com/docs/5.3/routing
This is actually something of your own choosing. If the operation is a sensitive one you might consider using POST so that you can have protection over CROSS-SITE REQUEST FORGERY from attackers but if not so you can simply use GET
If you only want save data in database(no return data) so you should use POST. And whenever you want to get data from database so you should use GET.
Ex - If you want to insert a new user information in database so here you use GET method and if you want to edit existing user information and return updated information so you will use GET method.
We have a legacy (php) aplication, accepting file uploads and they are stored at a path depending on the session id. Now we had to provide a very simple API for this webapp, where through an iOS api (iPad) a file upload is performed. We return an url which the customer will open in an embedded webkit window.
Because the sessions from the upload and view actions are different, we thought to grab the session parameter and return it in our response from the file upload. Then the client gets redirected to that url, we set the session id to the previous id and continue to the page the customer can continue the work.
Apparently, nothing I tried works. We use Zend Framework 1, but that shouldn't really matter. I tried:
Setting a Set-Cookie header (this results in a cookie containing two PHPSESSID values)
Use a setcookie("PHPSESSID", $session, 3600) to set the PHPSESSID
Use the Zend http Reponse with a setHeader('Set-Cookie', 'PHPSESSID=....', true)
The last two options just don't do anything, like I didn't set the session at all. How can I solve this? We actually can't touch the legacy code base that much to modify its working and change the way the path resolving works for file uploads.
So, the flow is:
Request to api.myapp.tld -> Response with a string in body -> Open webkit window with this response string as location -> Request is performed -> Response with a Redirect header and a method to set the cookie to something different -> Webkit performs redirect -> Customer gets to a page with same session ID as the first request to api.myapp.tld.
If there is an alternative to set the session id, it would be great.
That's not trivial to debug, but you have some options. I'm not fluent with Zend Framework 1.x, so this is not framework specific (frameworks sometimes add stuff on top), but PHP specific.
In PHP a session is identified by two things:
Name (example: a common default name is PHPSESSID)
ID (that is the random "number")
The Name allows to use multiple sessions at once, while the ID identifies the session in specific.
It sounds a bit you need to use two session IDs in parallel. I suggest you make the script that needs to deal with the legacy session to have another sessions name than your current script.
You can then pass in the legacy/old session id by using the other session name while your current session can remain as is.
I hope this information is helpful. If you have got problems to implement that, please ask.
I ended up by something simpler. The session was related to the path like this /path/to/location/ . $sessionId. When the second session was started, I simply renamed the directory from the old session to the new one. Simple and fast to get this working.
i am using Ajax to send JSON data over to my server for a php script to parse.
for example this is the JSON which will be outputted:
http://myserver.com/parse.php?user=123&point=100&callback......
and the "parse.php" script will GET the points in the URL and give it to that user which the user id is stored in the user=123.
However , if a person directly use "http://myserver.com/parse.php?user=123&point=100&callback......" on their browser without letting my javascript to initiate it , they can cheat their points , which they can set to any amount they like in the URL.
So how can i protect/authenticate the JSON request??
If you're passing the user points via an AJAX request or something similar client-side, then you simply cannot protect your application against cheating. Your user is telling the script he/she scored 100 points, how can you be sure that's the fair number? Pass over the initial data you're using to compute your score, like valid answers for the questions or whatever it is you're measuring.
If you have a login mechanism in your application, you could check for the valid credentials on the server-side when executing your script, without actually passing the user identifier via GET/POST.
Lastly, in your method you can check for the AJAX header and the referer ($_SERVER['HTTP_X_REQUESTED_WITH'] and $_SERVER['HTTP_REFERER']) to make sure the request comes from your JS code, but this is really just a minor tweak which is easy to compromize. Also, not every browser passes the referer header (depends on privacy settings), so further problems may arise.
Require Users to be logged in to invoke parse.php. If the request doesn't supply a valid session id, refuse to take action.
Don't put any game data and logic in client side.
Never trust the client. You always must calculate server-side.
More infos (don't rely on link title, there is a lot infos in answers) : https://gamedev.stackexchange.com/questions/3695/how-do-you-prevent-your-javascript-html5-web-game-from-being-copied-or-altered
I am trying to read a cookie which I've set with javascript, jQuery Cookie Plugin specifically, and then after that I'm reading it with PHP to write it into a database.
For some reason the cookie is being created on page load, but doesn't "exist" until the page is refreshed. Which means that I'm pumping blank fields into my database tables.
The only way I can think of doing it is to AJAX out to a script which creates the cookie. Or ajax out to a script which returns the data to me in json.
The use case is that I'm creating a simple analytics class for an internal project, and I'd like to write into the database the users resolution, colour depth and all that jazz, which I'm using screen.width etc to get.
Cookie data are sent to the server (and forwarded to the PHP interpreter) when the client performs the request. Therefore, a cookie set by JavaScript on the client after the page has been requested from the server will not be transmitted until the next request to same server.
What you'll have to do is to perform some kind of request (could be done via AJAX) where a PHP script handles the incoming cookie information and stores it in the DB.
#jensgram is right. These two scenarios can happen:
User requests your page and (s)he hasn't the cookie. You render the response via PHP, but you can't see the cookie at server. Response gets delivered to the browser and on DOMReady (or events like that) you set the cookie. User sends another request (via interaction with your page). Here you have the cookie at server.
User already has the cookie (coming back to your site) and sends a request. You render the response via PHP, but this time, cookie is available in first shot. The rest is the same.
Two suggestions:
To prevent inserting null (or empty) values into your DB, first check to see if cookie exists or not. If not, simply try to set it.
For implementing Analytics, predefined patterns exist. For example, instead of setting a cookie, you can include your script on every page, and on load of each page, you can get the information you need, and send an asynchronous ajax request to your Analytics Collector PHP file. No need for cookie :)
I'm building a PHP-based web app and am integrating a Flash-based charting engine. The Flash chart needs to make a AJAX request for its data. This request fails because it is seen as a new user agent and doesn't contain the PHP session cookie to identify it. So, it gets redirected to the login page.
I've read a few hacks to make this work, including supplying the session ID on the querystring, but that opens up security holes. How can I get Flash and PHP to share cookie-based session state automatically and stay secure?
In IE it will work naively. In firefox, the only way to achieve this is to POST the session id into the flash script (the php processor that is), and have it restore the session from that.
If the session cookie is initiated early enough, then it should be OK. I've had a similar problem with cookies shared between JavaScript AJAX and Flash requests (if you want to call that AJAX too, go ahead :-) ), and we solved them by making sure the JavaSCript finished the request that initiated the cookie early enough so that when the Flash sent the request, the browser already had the session cookie.
Also making sure the cookie path was set to "/" was a good idea.
That being said, if you can't get it to work - as dirkgently said - you can store the information in the HTML DOM using a JavaScript AJAX call, and then fetch it from the Flash object using an ExternalInterface call. But do make sure to set at least "allowScriptAccess=sameDomain" on your Flash object
You should be aware that transmitting a session ID in a Cookie: header, or in the argument field of the GET HTTP directive is of no different security.
Use ExternalInterface to talk to the Flex chart. Some browser related information can be passed around via the LoaderContext and BrowserManager classes as well. Dig in a bit into the AS3 documentation.
you can try and send to php 2 parameters one session_id and a second one that is an key that combines some information from the client ( ex ip ) and encrypt it with a key stored on the server and on the request from flash you check to see the second paramaters matches the client request, this way if somebody trys to do a session stealing they cant because they will not match the second param