More on cURLpp
I talked about cURLpp in my last post. There’s much more to it than just uploading files to Google Drive endpoints. A few things I discovered is :-
- curlpp::infos
This allows certain response info to be obtained directly. There are a list of info obtained, which can be referred from “curlpp/include/Infos.hpp”. A more useful one would be ResponseCode, which is great to have. After request.perform(),
long responseCode;
curlpp::infos::ResponseCode::get(req,responseCode);
and you can use the responseCode as you please.
- WriteStream
There is a ReadStream option for the request, which was previously used to insert a string stream into the body. On the contrary, there is WriteStream to feed the response output into a stream. On default without WriteStream option, the output is written to std::cout.
There are a few things we might want to do with the output, for one, parse the response (JSON, XML…) or save the stream into a file. Just for illustration:
std::stringstream responseBody;
req.setOpt(new WriteStream(&responseBody));
Refresh token
My daftness was once again proven having just recently found out about the refresh_token. Put simply, refresh_token is like a re-usable authorization code. There is much documentation provided here.
Few things to note about refresh_token:-
- It is used to obtain an access_token.
- access_type must be set to offline.
- It must be stored in a safe and secure database.
- It will not expire unless the user revokes the permission to the application.
- It is only given once after user authorizes the application*.
*If anyhow, you did not manage to store the refresh_token on first attempt, or misplaced the refresh_token, all hope is not lost. Just include “prompt=consent” as the query parameter when negotiating for the “code”.
Refresh_token will make things much easier for me without worrying access token expiry and not having a solid mechanism to renew it. A WTimer can be used to trigger an a backend mechanism for access token renewal whenever it pleases.
0 Comments