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 once when the server is first started. This takes the WSGI environment variables generated by your WSGI server as a parameter. Because of this, we reload the WSGI values on every request. This is done already for you by Masonite. This Request class is bound and 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:

def show(self, Request):
    # Request is the instance of the Request class
    pass

Masonite is smart enough to know that we need the Request class and it will inject it into our method for us.

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:

def show(self, Request):
    Request.input('username')

def show(self):
    request().input('username')

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:

def show(self, Request):
    Request.input('username')

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.

def show(self, Request):
    return Request.all()

To check if some request input data exists:

def show(self, Request):
    return Request.has('variable')

To get the request parameter retrieved from the url. This is used to get variables inside: /dashboard/@firstname for example.

def show(self, Request):
    return Request.param('firstname')

You may also set a cookie in the browser. The below code will set a cookie named key to the value of value. By default, all cookies are encrypted with your secret key which is generated in your .env file when you installed Masonite.

def show(self, Request):
    return request.cookie('key', 'value')

If you choose to not encrypt your values and create cookies with the plain text value then you can pass a third value of True or False. You can also be more explicit if you like:

def show(self, Request):
    return request.cookie('key', 'value', encrypt=False)

You can get all the cookies set from the browser

def show(self, Request):
    return request.get_cookies()

You can get a specific cookie set from the browser

def show(self, Request):
    return Request.get_cookie('key')

Again, all cookies are encrypted by default so if you set a cookie with encryption then this method will decrypt the cookie. If you set a cookie in plain text then you should pass the False as the second parameter here to tell Masonite not to decrypt your plain text cookie value. If you do not do this then Masonite will throw an invalid token exception:

def show(self, Request):
    return Request.get_cookie('key', decrypt=False)

This will return the plain text version of the cookie.

You can also get the current user from the request. This requires the LoadUserMiddleware middleware which is in Masonite by default. This will return an instance of the current user.

def show(self, Request):
    return Request.user()

You can specify a url to redirect to

def show(self, Request):
    return Request.redirect('/home')

If the url contains http than the route will redirect to the external website

def show(self, Request):
    return Request.redirect('http://google.com')

You can redirect to a named route

def show(self, Request):
    return Request.redirectTo('dashboard')

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.

def show(self, Request):
    return Request.back()

This is equivalent to:

def show(self, Request):
    return Request.redirectTo(request.input('back'))

You can also specify the input parameter that contains the named route

def show(self, Request):
    return Request.back('redirect')

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.

def show(self, Request):
    return Request.back().send({'firstname': 'Joseph', 'lastname': 'Mancuso'})

    return Request.redirectTo('dashboard').send({'firstname': 'Joseph', 'lastname': 'Mancuso'})

You can load a specific secret key into the request by using:

Request.key(key)

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