Automatic management of tokens for API in general #34
Conversation
| Future<Dio> getClient() async { | ||
| final Dio _dio = Dio(); | ||
|
|
||
| _dio.options.baseUrl = '$_baseUrl/api/v1'; | ||
| _dio.interceptors.clear(); | ||
|
|
||
| _dio.interceptors.add(InterceptorsWrapper( | ||
| onResponse: (Response response, handler) async { | ||
| var data = response.data; | ||
|
|
||
| if (data['error'] != null) { | ||
| log(data.toString()); | ||
| throw ApiException(data['error']); | ||
| } | ||
|
|
||
| // save access token (refresh token is auto-saved by CookieManager above) | ||
| if (data['payload']?['accessToken'] != null && data['payload']?['accessToken'] != '') { | ||
| await storage.write(key: 'jwt_access', value: data['payload']?['accessToken']); | ||
| } | ||
|
|
||
| return data; | ||
| }, | ||
| )); | ||
|
|
||
| return _dio; |
There was a problem hiding this comment.
Do you think we should just go with getClientWithAuth alone, since it's probably good to make all our API requests authenticated even if not yet necessary (maybe validation is added later)?
There was a problem hiding this comment.
Actually, I think there's a way to extend the Dio client, which would make ApiService itself available for running gets, posts, etc. with the credentials automatically applied. See here: https://pub.dev/packages/dio#extends-dio-class
Not sure if this will do what we need it do though, as the docs aren't good in this section. It may allow for the removal of the getClient method though, which I think makes things clearer when the code is used.
There was a problem hiding this comment.
If we want to use just getClientWithAuth, then we need to modify it to allow request even if there is no access token (for /section/search and /course/search). Extending the Dio class would be nice, but I don't see the need for it at the moment. If you are able to do it without much hassle, sure go for it.
There was a problem hiding this comment.
If we extend the class, we could pass an additional option (part of options) to distinguish between auth & no-auth requests.
There was a problem hiding this comment.
Yeah extending the Dio class may be as much of a hassle as extending IOClient is. Does running a /section/search with some query parameters and an access token cause an error?
If it does, then I suppose we will need to have separate code paths for authenticated/unauthenticated requests. I propose changing the method getClient to use a keyword argument credentials or auth or something that can be true or false.
|
Should I close this pr since we're probably going to use the api-test? |
Using Dio, I add interceptors to attach
access tokento headers &request tokento the cookie (using CookieManager). Also created request clients to make requesting easy -- divided into two client types:getClientandgetClientWithAuth.getClientis a normal request client, no authorization.getClientWithAuthis a request with cookie & header pre-attached.Both clients' response is parsed and checked for new
access token.