Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Unable to get page" on private wiki #199

Open
YukinoHayakawa opened this issue Jun 14, 2023 · 3 comments
Open

"Unable to get page" on private wiki #199

YukinoHayakawa opened this issue Jun 14, 2023 · 3 comments

Comments

@YukinoHayakawa
Copy link

YukinoHayakawa commented Jun 14, 2023

Hi. I'd say the ability to edit MediaWiki pages with Sublime Text provided by this extension is wonderful and very useful to me and thank you very much for developing it! However I've encountered a weird issue during my daily use.

I have a private wiki setup like this:

"PrivateWiki":
{
    "authorization_type": "login",
    "host": "xxx.com:<custom_port>",
    "path": "/wiki/",
    "pagepath": "/wiki/index.php/",
    "username": "<bot_username>",
    "password": "<bot_password>",
    // set to false because this is not working with custom port
    "is_ssl_cert_verify": false,
}

By private I mean one must login in order to read and edit.
When I first open Sublime Text or have triggered a reconnection to the site, everything works fine. e.g. If I triggers:

'''Setup new connection to "PrivateWiki".'''
Connecting to "https://xxx.com:port" ..  done.
Login in with authorization type login..  done

or

'''Site configuration is changed, setup new connection to "PrivateWiki".. '''
Connecting to "https://xxx.com:port" ..  done.
Login in with authorization type login..  done

Then I'll be able to see

  >>> Page [[title]] does not exist. You can create it..
Page [[title]] was opened successfully from "PrivateWiki".

However, if I leave the editor for somewhile, later operations will always fail reporting

  >>> '''DEBUG''' Get connection from connection manager.
  >>> '''DEBUG''' Cached connection: True
  >>> '''DEBUG''' Get connection from connection manager.
  >>> '''DEBUG''' Cached connection: True
  >>> Unable to get page "title", APIError exception raised: ('readapidenied', 'You need read permission to use this module.', 'See https://xxx.com:port/wiki/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt;https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/&gt; for notice of API deprecations and breaking changes.')

The message had been confusing me for a while, until I finally tried to read the source code and found that some attempts to read the page were made before a logged-in connection is ensured, basically trying to anonymously read the page before the operation like open/save actually proceeds. The only workaround is to relaunch the editor or modify the connection setting in order to force a reconnection. Either way is equally annoying. Is there any error in my configuration? Or what would you suggest? Thank you in advance.

Edit:

I suspect there might be something to do with the site's session alive time/etc. Because even when I'm editing the wiki on webpage, if I have kept the page open for too long, when I submit the change it will also report something like session expired and let me retry. The thing is the get_connect() function in mw_utils.py doesn't seem to check whether the connection is still valid when it returns a cached connection. I don't know whether this check will be trivial to do with mwclient. What I'm doing now is to comment out the lines of code that return cached connections and always make a new one.

@tosher
Copy link
Owner

tosher commented Jun 26, 2023

Please, try the new version (v3.6.15)

@YukinoHayakawa
Copy link
Author

I'm sorry but after the upgrade (I'm pretty sure that I actually upgraded the package as I checked the python scripts to make sure they match with your latest commit and my plugin_host.exe run with the correct package folder) but it appears to me that the problem persists in the very same way 😢

@RheingoldRiver
Copy link
Contributor

This patch if you checkout a new branch locally and apply it, should fix the issue, although it's a rather inelegant & brute-force approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants