Blueprint Secure Networking Interface
With version 47.1 we removed the implementations of all pre-existing blueprint exposed HTTP functions. These were untracked and on manageable, so we have implemented a new system.
IMPORTANT NOTE:Â Custom Cosmetics mods cannot send network requests. No exceptions, they are blocked from doing so. Any attempts to circumvent this will be dealt with.
Some of the important benefits of this new system include:
* Can be implemented on any blueprint.
* No longer need to filter through responses for other mods, the instance that makes the request will recieve the response directly
* Called endpoints can now be tracked to a mod directly
* Users and Server Admins can see at glance what mods are sending requests to what endpoints
* request audits allow mod authors to protect their mods from unauthorized requests being sent in the name of their mod
Implementing this new system is actually quite simple, there are just two major rules:
* The Blueprint that is calling the HTTP functions MUST implement the BPSecureNetworkingInterface in order for the request to be sent
* When implementing the interface the appropriate "Audit" function must be implemented and handled
Note: It was already brought to our attention that an HTTP function in a CDO class called MoviePipelineBase was being used for some more advanced functionality. We will be expanding this system to restore the features that were lost by that implementation being deprecated.
**UPDATE** This document has been updated to focus on the HTTP Request (Advanced) implementation but the old HTTP GET request and POST request implementations will continue to exist and work. Just understand that those older methods do not have request IDs or timeout support
Step 1: Add the interface
The first step is to figure out what blueprint you want to use to send and receive network requests. On this blueprint go to Class Settings and then to the Interface section. Search for BPSecureNetworkingInterface and add it.
This will add a set of events and implementable functions to your blueprint. you do not have to use all of them, only implement what you need.
The Audit functions are a key component, if they are not implemented then requests of that type will not be sent by the game at all.
Step 2: Set up a request audit
The Audit functions are you opportunity as a mod author to ensure that the requests being sent in the name of your mod are legitimate and not being used as a vector for exploitation.
Their use is simple; returning True will allow the request to be sent, False will block it.
The example to the left will return true ONLY IF the specified header is NOT present and the URL endpoint is one that has been allowed.
A bare minimum that we recommend is maintaining a list of endpoints that you are intending to use and checking to make sure the URL is one of those listed.
Step 3: Send Network Request
In the same blueprint that you implemented the Secure Networking Interface, call the HTTP Request (Advanced) function that you set up an audit for in step 2.
Please note that these functions can be called even if you have not implemented the Interface, but they will not send the request in that situation.
The example to the right is sending 2 requests. The first will succeed because it is the allowed endpoint checked for in the audit function. The second request will fail due to the presence of the header that is being checked for in the audit implementation.
The VERB Parameter is determined by support on the server the request is being made to and header data may be required for validation.
When using the Advanced HTTP Request you will have the option to set timeout and will receive a valid request ID if the request is actually sent.
The Timeout will trigger an event On HTTP Request Timed Out
Important note: There is a known issue (Discovered as I was updating this documentation) where if a request fails to be sent that the last request ID created will be returned. this is an error and will be fixed in a subsequent update. In the future it will return a value of -1 when the request fails
Step 4: Handle the response
In the blueprint implementing the networking interface you will also see the On HTTP Response event. For the same request type that you have implemented, you can add the event here in order to handle the response.
The example image to the left is just printing out the full response as a string in the log.
For any request failures or audit failures these events will be logged under the category ASANetLog
I'm sure some might be wondering why we have implemented a system of audits. While the caller registration of the request functions seems pretty reliable we can't assume that there isn't some kind of hack that can be achieved by editing blueprint nodes manually. The Audit allows the engine to ask the registered caller directly if the request it is about to send is actually one it wanted to send.
The audit system and the underlying native implementation also gives us the ability to identify what mods are making what requests. While something like a fiddler trace could let us view outgoing requests before, it was nearly impossible to tell what was making the request within the game, this new system allows us to see what mod, class and instance is making a request. If a mod fails to implement adequate security on their calls and ends up being used by another mod for exploitation or abuse, we can revoke the network permissions of that mod directly until such time that the mod author can handle the weakness in their auditing.