You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prompted by @pfefferle, and something I'd considered in the past. The biggest issue is migration, but I'd deliberately built into the plugin a class the token storage classes are all inherited from. There are currently two...one that stores as a transient, the other as user meta. I would just have to improve that abstraction a bit.
The advantage of the current system is its simplicity, but things have gotten more complicated since I did it. So, proposal is as follows.
Introduction of new custom post type to store tokens, mapping the following properties to post properties:
'me' - since this is a function of the author, it would be derived from the post_author property
'scope' - Could be stored in the excerpt or content
'client_id' - Proposed client data be stored as a taxonomy attached here, which could also be attached to posts in micropub
We have 3 time properties...
'iat' - When the token was issued, which usually maps to published as an equivalent
'exp' - When the token expires(which is optional), not sure where to store this...I suppose meta is the best place, as the expiry dates of all tokens could be picked up in a single query, but...
'last_accessed' - which is when the token was last used and could reflect modified
'last_ip' - We also store the last IP address.
'uuid' - Never used this, but wanted a way to uniquely identify a token...so this could be replaced with post_id.
The text was updated successfully, but these errors were encountered:
80-90% of the content feels like it'd end up being stored as meta, so my gut tells me just store it all as meta instead of most of it. It's most definitely possible to fetch all meta for a post in one go, and go from there. Realistically how often are these values going to be added to NEW posts as opposed to UPDATED posts? Assuming part of the mitigated problems are intended to be post/post meta bloat? Given that we're often working with personal sites, as opposed to to-be-grown community sites, probably NOT that many new posts.
Prompted by @pfefferle, and something I'd considered in the past. The biggest issue is migration, but I'd deliberately built into the plugin a class the token storage classes are all inherited from. There are currently two...one that stores as a transient, the other as user meta. I would just have to improve that abstraction a bit.
The advantage of the current system is its simplicity, but things have gotten more complicated since I did it. So, proposal is as follows.
The text was updated successfully, but these errors were encountered: