It works when I revoke the grant. Not tested with a naturally-expired refresh token, yet.

Food for thoughts : https://codeberg.org/Gouvernathor/m3api-oauth2/commit/d456515b032bd19ec77b4d3d36e830be9af17a03

Yes, I guess that's it.

Sure. For me the last brick is to correctly interpret the refresh failure as an expiration of the refresh token. We could just have the tokens erased whenever the refresh query returns a non-200, but that could have false positives – and there would be no real added value of the oauth2 layer wrapping that in a new error type, rather than just bubbling up the error returned by the vanilla session.

So we're on the same page (and we don't lose sight of the end goal), these last two commits ensure the refreshed access token is updated and persisted, but don't handle the original goal of the task, which is to handle when the refresh token expires and the refresh operation fails.

Well, one thing I changed when making my version of the package is to take a third constructor parameter that's the serialization, and document that in favor of mutating an serializing in-place – before seeing that the refresh mechanism requires mutation and the complete mechanism is considerably more complex without it.
Now, your version is fully mutation-oriented, so I'd say it's worth something if the mutation mechanisms are as reliable as possible even in complex situations.

I think you need to serialize the session at the end of each request anyway?

Oh, right. Then yes, it would work.

No, your version would not work, because it would make it impossible for anyone importing your package from accessing anything except the node submodule. The browser version would be completely inaccessible, and m3api-oauth2's import of /core.js would fail as well.
(Unless on old versions of Node which would ignore the "exports" entry I guess, but that's not a very workable standard.)

In that version, the browser importers could and would import the node version when import {} from "m3api". That's legacy behavior and I can understand your reluctance to change it, but it's probably not the best behavior.
Note that it's possible to have the following :

Note : the bug is circumvented (as shown in the second version of the file) by setting a size in px AND THEN an overriding size in rem.
The fact that the Commons rasterizer visibly uses the px version implies, as I understand it, that it recognizes a rem value as an incorrect value and ignores it – meaning that the issue is not something else, like the rasterizer having another value for rem than 16px for instance, which could have been another explanation.
It also means that the bug has presumably nothing to do with the width, height and viewBox as I mentioned earlier.

Well, apparently I'm now unlocked

Nvm. They were the files in public_html/svgfiles, but the problem came from the fact that an absolute path to the main tool was used, and called from the beta tool, which resulted in obvious permission errors.
Using relative paths solved the issue.
Thanks for the response.

Hi, I'm having an issue porting a cron task we used to the new system.
The task needs to remove old files, but there's a permission error and it doesn't have the right to rm any of them.
I scheduled the tool using the tool account.
What can I do, where should I start ?

I did figure it out by telling .lighttpd.conf to use python3 to handle the .py requests.

Thanks. I restarted the webservice and it seems to work better (no 403, and the subpages have the js working properly, and the php subpages are accessible).
There is an error with a place where we call a python file from the js, and the result doesn't seem to be what it was before - but I'm not sure how it did work, either.
The thing is that we're making a POST ajax request to the python file. Before, it executed the file and returned what the file printed (the name of a generated SVG file). Now, it returns the entire file...
I guess I'll figure it out.

Hi, I'm associated with Slashme for maintaining ParliamentDiagram.
I understand the tool has been disabled, but I don't quite understand the context and reasons about it, or what I need to do in order to migrate (or where to migrate to).
What's most surprising to me, is that a sort of copy of the parliamentdiagram tool, called parliamentarch, is still standing and working quite well, despite the fact that I didn't do anything to maintain it throug that migration thingy.
Edit: actually it doesn't seem to work either, but it's nonetheless considerably less broken.

I think you meant it has Python 2 implementation which should be dropped.
Indeed, the methods inherited from MutableMapping do the trick, so the three methods defined in the Request class should simply be removed.