The Invision Community software includes a class to work with request data, including GET, POST, and REQUEST data, cookies, and detecting certain information about the request (such as whether it was submitted via AJAX or not). You will need to use this class to perform some common actions working with web-based software. The class is accessed through \IPS\Requst::i() and implements the Singleton pattern.
GET, POST and REQUEST data
To access request variables, you simply call them as properties of the class. For instance, you can check if a request variable is set and output it like so
if( isset( \IPS\Request::i()->someVariable ) )
{
print \IPS\Request::i()->someVariable;
}
Request data is largely unmodified from the originally submitted data except that NULL bytes and RTL control characters are stripped from the input, and slashes are stripped if magic quotes is enabled. This means that all request data should be considered potentially tainted and you will need to take precautions not to introduce security issues by relying upon "clean" request data from this class.
If the request is made using the PUT method (which happens through our REST API in some cases, for instance), this request data is also available through this class.
Working with cookies
Cookie values are available in the cookies property of the \IPS\Request class.
print \IPS\Request::i()->cookie['member_id'];
If your site uses a cookie prefix, note that it will be stripped automatically here.
To set a cookie, you can use the setCookie method. As with fetching a cookie, you should not include any cookie prefix that is used. The method signature is
/**
* Set a cookie
*
* @param string $name Name
* @param mixed $value Value
* @param \IPS\DateTime|null $expire Expiration date, or NULL for on session end
* @param bool $httpOnly When TRUE the cookie will be made accessible only through the HTTP protocol
* @param string|null $domain Domain to set to. If NULL, will be detected automatically.
* @param string|null $path Path to set to. If NULL, will be detected automatically.
* @return bool
*/
public function setCookie( $name, $value, $expire=NULL, $httpOnly=TRUE, $domain=NULL, $path=NULL )
Typically you should leave $domain and $path as NULL, however these can be overridden if needed, for instance if you are working on integrating with a third party service.
You can clear all login cookies through \IPS\Request::i()->clearLoginCookies() if needed, which includes the member_id and pass_hash cookies, as well as any forum password cookies (where a user may have entered a password to access a forum).
Other helper methods
There are several helper methods in the \IPS\Request class that you can leverage as needed to check various properties of the request
-
\IPS\Request::i()->isAjax()
Returns a boolean true or false to indicate if the request was made via AJAX -
\IPS\Request::i()->isSecure()
Returns a boolean true or false to indicate if the request was made over SSL (https) -
\IPS\Request::i()->url()
Returns an \IPS\Http\Url object representing the requested URL. Note that fragments (values after the hash symbol in a URL) are not sent to the server and will not be available to check at the server level. -
\IPS\Request::i()->ipAddress()
Returns the IP address used to make the current request, taking into account proxy servers and forwarding if the administrator has chosen to do so in the AdminCP. -
\IPS\Request::i()->ipAddressIsBanned()
Returns a boolean true or false to denote if the current request IP address is banned in the AdminCP IP address ban filters. -
\IPS\Request::i()->requestMethod()
Returns the current request method, upper-cased. -
\IPS\Request::i()->isCgi()
Returns a boolean true or false to indicate if the current request is being processed by a CGI wrapper in PHP -
\IPS\Request::i()->floodCheck()
Checks the user's search flood control setting to determine if the user has recently searched and is searching again too quickly. If the user has searched recently and this method is called before the flood control time period has completed, an error will be shown to the user, otherwise their "last searched" time is updated to the current time for subsequent checks. -
\IPS\Request::i()->confirmedDelete( $title, $message, $submit )
When a user deletes data, it is prudent to confirm that the action was intended and not a misclick or similar. To facilitate this you can call the confirmedDelete() method which will verify if the user has confirmed the deletion already, and if not will show a confirmation screen first.
Report Document