I don't see T245012, T226942 as blockers for PAWS.

In T51541#5847780, @Juandev wrote:

Hey, is it set for whole wiki or is it just a user script? If there are people, who think its not worth coding, why not to have it as an option. I would love to use it on cs.pw, commons, cs.wv etc.

Setting up the Wiki-Loves-Love bot for this year I decided to take advantage of CronJobs. I placed my example CronJob yaml definition and some notes on how to debug it in the Wikitech page.

yeah, my plan then is to actully go the full k8s route with prometheus-operator and such. Have not gotten around to implementing it yet.

Does this include updates to the toolforge prometheus instance? I wanted to funnel PAWS metrics there but it was such an old version when I tried it I gave up on getting it to work.

In T236446#5750583, @zhuyifei1999 wrote:

Google isn't responding (they probably don't have the incentive to), gonna wait for a few more days. If it stays like this, I'm gonna get a massive overhaul to how v2c download from YouTube. sneek peek: slimerjs + x11vnc

Seems to be missing a few edits I made a few hours ago with my bot https://xtools.wmflabs.org/autoedits-contributions/pt.wikipedia.org/ChicoBot v https://pt.wikipedia.org/wiki/Especial:Contribui%C3%A7%C3%B5es/ChicoBot

https://meta.wikimedia.org/w/index.php?title=Special:OAuthListConsumers/view/bf7eb39a895d1987ef9300b782fc948b&name=PAWS&publisher=&stage=-1 is the last one, probably not a lot of edits there though

How do we get the CIDs?
How to translate 0a73e346a40b07262b6e36bdba01cba4 to 429?

Maybe add PAWS and the OAuth consumer version as the client in the meantime?
BTW, there are 5 past PAWS OAuth consumers and I will (hopefully) soon move it to a sixth one (T243200).

This does not seem to be the underlying issue here, but PAWS will not have admin permissions. T192237

It has been a while, but I have a working script to add thanks links over at https://github.com/chicocvenancio/wiki_scripts/blob/gh-pages/thankLinksInWatchlist-pt.js It is localized to portuguese and doesn't quite handle genders properly right now, but if there is interest I could clean it up and add i18n for it.
I copied a few of the functions from ext.thanks and added the links manually to the dom.

Sure, makes sense.

@bd808 I don't think these are duplicates. As I understand T174469 is a backend problem that makes accounts that are not attached to Wikitech not have a way to reset passwords. This is more of a feature request to have some indication in Striker of how to reset passwords.

Adding a link to https://wikitech.wikimedia.org/wiki/Special:PasswordReset might be good enough to avoid confusion.

Thanks @Krenair

That was it, thanks @Phamhi.

having a separate OAuth flow

This is the part that is complicated in my view, specially doing this securely and with a good UX in PAWS.

Hey @Tgr, I'm not sure setting up automatic OAuth with the beta cluster is straightforward. The reason we can do it with the production wikis is we authenticate the user with them and just use the same OAuth tokens to pass to Pywikibot. As I understand it, there is no way to authenticate with production wikis and use that session with the beta-cluster, so we would need to setup a different authenticator for PAWS specifically for the beta-cluster, this is not impossible but I fear it is a significant amount of development and may create confusion for normal users.

Thanks for creating this ticket. The pod was stuck in terminating state in the node tools-paws-worker-1007 for the past couple of days. I removed it with kubectl -n prod delete pod jupyter--43riscod --force grace-period=0 perhaps someone with root access should check docker to see if/why the container is still running.

@Dominicbm I agree this is a great improvement for PAWS. Unfortunately I do not have the bandwidth to develop this for the foreseeable future and no other volunteers have stepped up.

@Kymybot ?

In T228500#5350594, @bd808 wrote:

I really want to get to <tool>.toolforge.org (T125589: Allow each tool to have its own subdomain for browser sandbox/cookie isolation), but we will still need to support tools.wmflabs.org/<tool> somehow. This might be something that we continue to do in a layer in front of the Kubernetes ingress though.

I've tested with and without the UserAgent, it sometimes works when defaulting to the SPARQLWrapper agent, but without looking at server logs and configuration I don't have much clue on why this is happening. Perhaps someone can investigate and tell us.

In T230135#5403134, @OlafJanssen wrote:

@Chicocvenancio Thanks for elegant your solution. I looked at https://stackoverflow.com/questions/10606133/sending-user-agent-using-requests-library-in-python
I added this the notebook, is that a valid approach as well? (I'm not experienced with this sort of stuff yet)

---

import requests
url = 'http://www.kb.nl'
headers = {

'User-Agent': 'My User Agent 1.0',
'From': 'olaf.janssen@kb.nl'  # This is another valid field

}
response = requests.get(url, headers=headers)

Indeed setting a different agent works. https://paws-public.wmflabs.org/paws-public/User:chicocvenancio/T230135.ipynb

This seems relevant https://github.com/RDFLib/sparqlwrapper/issues/139

BTW you can use a ! to run commands directly from the notebooks. IE use !pip install sparqlwrapper instead of using the terminal every server start. see https://paws-public.wmflabs.org/paws-public/User:chicocvenancio/T230135.ipynb

This seems to be an HTTP response from https://query.wikidata.org/

@Mohinem how are you trying to login? There is no login required for Wikimedia wikis.

It seems this is an artifact of the packages installed in the singleuser image clashing in some way. I don't know what packages are the source of this error and have not had the time to investigate this more closely.

In short, currently, don't.

@bd808 should we ask for a VPS project to have a subdomain we can verify ourselves or is there a way to verify tools.wmflabs.org itself?
I would think of having a simple proxy to Toolforge with nginx if a project is indeed necessary.

Not quite sure what happened, while it still shows up on @Jampo001's notebook. Trying again from PAWS just now got me no errors.

Sorry, this was in PAWS, so maybe something we're doing with Auth there is messing this up.

Finally tracked this being due to helm attempting to talk directly to k8s with the pod's serviceAccount instead of the Tiller one.
It works again.

Where are the project rooms?
The project rooms are on the 4th floor.

@Xqt do you mind rebasing that PR? or allowing me to rebase the changes there?

I'm trying to fix this task in Wikimedia-Hackathon-2019. Hopefully we can start accepting and merging PRs for PAWS image changes soon.

@TuukkaH mentioned this task to me at the Wikimedia-Hackathon-2019. I see your VPS project already has an unused floating IP address quota.

Thanks @bd808. This can be closed then.

cloud-services-team Could someone check the Icinga settings for the PAWS page? Just making sure it includes the /paws url path before closing this?

I'm slightly afraid this will lead to more confused users, but I'll change this and see if any complaints pour in.

I would be interest in talking to the pwb devs there. Not sure if there is enough audience for a session, but I'm interested in meeting and talking to you guys if there is not a session.

In T196207#5113410, @Harej wrote:

I think the PAWS OAuth grant should, theoretically, entertain the idea of admin actions via PAWS. I don't really have good insight on what form this takes. It could, for example, be two different options for permissions grant: the usual one, and a sudo mode with admin privs attached.

That is T192237. Yeah, we could have multiple Wikimedia oAuth consumers, one without admin permissions to limit attack surface and one with them to allow users to use admin powers. However a lack of oAuth v2 support in mediawiki (T125337) means it would take a lot of PAWS-specific development to get any oAuth done in a safe way(T120469). While I mostly feel confortable leaving that avenue open as it stands, opening the possibility of admin actions through PAWS means a step too far in my view. One year and a day ago I created T192237, since no one has commented there for us to enable admin actions despite the lack of security inherent in the current setup I am taking this as a very niche feature that hopefully can be taken care of once Mediawiki allows oAuth v2.

@Bstorm do we have a timeline on the NFS side of things? I would want to have an updated version of PAWS (hopefully capacity tested) before the Wikimedia-Hackathon-2019 next month. If it is not viable to do this move before then I would do the upgrades in place (though I'll then need root time to update k8s in tools).

@Harej Should we turn this to a feature request make PAWS add oAuth credentials to some requests to Wikimedia projects or close it?