Requests
Requests
Introduction
The Request class is initialized when the server first starts and changes based on every request by the framework. The Request class is loaded into the IOC container so any Service Provider will have access to it. The IOC container allows all parts of the framework to be resolved by the IOC container and auto inject any dependencies they need. Read more about the IOC container in the Service Container documentation.
Getting Started
The Request
class is bound into the IOC container on every request. This takes the WSGI environment variables generated by your WSGI server as a parameter. This is done already for you by Masonite. This Request
class is initialized inside the AppProvider
Service Provider. We grab this request object by simply passing in Request
into the parameters of anything resolved by the Service Container such as middleware, drivers and controller methods like so:
Helper Function
Masonite ships with a HelpersProvider
Service Provider which adds several helper functions. One of these helper functions is the request()
function. This function will return the request object. Because of this, these two pieces of code are identical:
Notice we didn't import anything at the top of our file and also didn't retrieve any objects from the IOC container. Masonite helper functions act just like any other built in Python function. Read more about helper functions in the Helper Functions documentation.
Usage
The Request
has several helper methods attached to it in order to interact with various aspects of the request.
In order to get the current request input variables such as the form data during a POST
request or the query string during a GET
request looks like:
NOTE: There is no difference between GET
and POST
when it comes to getting input data. They are both retrieved through this .input()
method so there is no need to make a distinction if the request is GET
or POST
Method Options
We can get all the request input variables such as input data from a POST form request or GET data from a query string. This will return all the available request input variables for that request as a dictionary.
To check if some request input data exists:
To get the request parameter retrieved from the url. This is used to get variables inside: /dashboard/@firstname
for example.
You may also set a cookie in the browser. The below code will set a cookie named key
to the value of value
You can get all the cookies set from the browser
You can get a specific cookie set from the browser
Get the current user from the request. This requires the LoadUserMiddleware
middleware which is in Masonite by default but commented out. This middleware should only be used if you have a valid database connection. This will return an instance of the current user.
You can specify a url to redirect to
If the url contains http
than the route will redirect to the external website
You can redirect to a named route
You can also go back to a named route specified from the form input back
. This will get the request input named back
and redirect to that named route. This is great if you want to redirect the user to a login page and then back to where they came from. Just remember during your form submission that you need to supply a back
input.
This is equivalent to:
You can also specify the input parameter that contains the named route
Sometimes your routes may require parameters passed to it such as redirecting to a route that has a url like: /url/@firstname:string/@lastname:string
. For this you can use the send
method. Currently this only works with named routes.
You can load a specific secret key into the request by using:
This will load a secret key into the request which will be used for encryptions purposes throughout your Masonite project. Note that by default, the secret key is pulled from your configuration file so you do NOT need to supply a secret key, but the option is there if you need to change it
Last updated