Open neslihanturan opened 6 years ago
But login fails for blocked users. Then how can this be done?
login fails for blocked users
@ShridharGoel Are you sure about this?
https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Common_blocks_imposed seems to say that blocked users are only blocked from editing, not from logging in.
@neslihanturan I was just going through the AuthenticatedActivity class. Once we acquire the authCookie how do we check if the user is blocked? I went through some files but I wasn't able to find any suitable function.
@neslihanturan Do you know where the information regarding whether a user has access to edit content is stored? Is it within the type field of the Account class? Or do I maybe have to make an API call somewhere to access this data? I'm probably way off, but any help would be appreciated since this is my first time working on an open source project!
@nicolas-raoul I am just curious to know if anything decided on this? Can you confirm if user will be able to login successfully or not? By the way, is somebody working on this?
It would be best to ask @neslihanturan about this, but AFAIK blocked users can login, except all their uploads will fail.
I was taking a look at it, but if this is important, then someone else may want to do it since this is my first time working on the project
@seannemann21 I wouldn't say this is necessarily urgent. Anyone who wants to can feel free to try and work on it. :) But it might be a bit tricky indeed. I am not so sure how to find out if the user is blocked, either.
There's a MediaWiki API that can be used to get information about the user.
https://www.mediawiki.org/wiki/API:Userinfo
In addition to blockinfo
, the API can be used to get quite a few other user properties as well.
Just a little suggestion. It might also be better to indicate this by dimming/fading the user profile icon (the commons logo along with the username) found in the sidebar of the app.
Ok yeah I found that API after I asked! I wasn't sure if I should make a call to it every time an authenticated activity is opened? Or store the blocked info in one of the objects? I'm not sure if this would lead to too many API calls, but someone could be blocked while they're using the app and then the block status would be outdated
Also, does anyone know how I can block myself for testing purposes? It seems like I should just be making the API call to check blockinfo like you guys said to check if the user is blocked, but no info concerning being blocked is present in the result (as you can see by following the link below). I am thinking this may be because I am not blocked. Regardless, I'll need to be able to block myself for testing purposes.
Thanks for the help by the way!
Alternatively, I could check to see if the user has the "edit" right since that is why we are checking to see if the user is blocked in the first place by issuing the following API call found in the following link
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=xml&meta=userinfo&uiprop=rights
Any input would be greatly appreciated!
@seannemann21 Please ask here: https://commons.wikimedia.org/wiki/Commons:Village_pump Create a separate account and ask them to block it. Thanks! :-)
Thank you very much!
(Test account is duly blocked; if you need unblock just leave me a comment o_o)
Thanks! just to double check, did you block the seannemann21 or the seannemann1234 user?
Looks like the seannemann 21 account! Thank you very much! Everything appears to be working, well as far as the api call to check for a block. Should be able to get the rest of the stuff finished for this issue in the next day or two. Sorry, I've been a little busy
@revi sorry, I am getting some unexpected behavior. Which account did you block?
OK I'm just kinda thinking out loud here. It appears seannemann1234 is the account that is blocked, but once I sign into the account the is blocked, if I sign out and then sign into an account that is not blocked, without closing the app, then this account will be blocked for the duration of this session as well. Also, if I am automatically logged in upon opening the app (i.e. I didn't log out before closing the app last time so I bypass the login screen this time) then the API call will not say that I am blocked, even if I am signed into a blocked account. Presumably because something was not set up correctly since logging in was bypassed
https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Log/Revi would tell you what account is blocked.
Thanks! That seems to makes sense. Just confused me that when I sign into one account, then the rest show as blocked unless I close out of the app
The authcookie should be cleared upon logging out, correct?
@seannemann21 I can't guarantee everything is cleaned on logging out (but of course it should be).
When it comes to where to make API call, what about checking it on upload process? Since user won't be able to upload when they are blocked. Besides we can check it on notification fetch (in notification acitivty).
Thanks! That would make sense to do it on the upload process! Seemed odd to have it pop up whenever you opened any authenticated activity
Also thanks for the cookie info! For the record, I misspoke before when I said if you close the app you'll be able to sign into an unblocked account and have full functionality. You have to reinstall it to regain full functionality if you signed into a blocked account before
@revi can you unblock the account seannemann1234 and then block the account seannemann21? I just want to ensure everything works as expected when an account has been unblocked
I think I am just going check for the block when an authenticated activity is created, using a snackbar to inform the user since that was what was originally asked for
Also I noticed that if two snackbars are shown on screen, then the second will immediately replaced the first. I could create a queue to handle snackbars, but should a create a separate issue for this?
@revi can you block the seannemann21 account with a block at expires sometime tomorrow? Anytime works. I wanna see how expired blocks work (like if any information is returned from the api call)
@revi let me know if you are/arent able to unblock/block those accounts!
I'm going to go ahead and submit a pull request since the only thing I was afraid of was if when a block expired, the block information still remained when you queried the API for block info; however, I am now checking the actual expiration time of the block as opposed to just checking if an expiration time exists.
Thank you very much to everyone that helped me! Also, sorry it took so long! I was a bit busy, and this is my first ever pull request.
Sorry, was busy IRL. Done.
Thanks! Can you actually change that expiring block to an hour from now?
Actually don't worry about it. Thanks!
Actually unblocked. (Since it was over 1h)
Thanks!
Implemented at #1573
Relevant PR is merged but it appears to be not working.
I just got blocked (block for proxy apis because I tried to upload image using Flixbus WiFi), and attempts to upload image failed with "Failed" showing after image was uploaded and no feedback why it failed.
I noticed what is happening only because I tried to upload directly from Wikimedia Commons website
@matkoniecz as far as I understand, your account was unblocked but just the proxy you tried was blocked? We may need to create a new issue for this. I think the responses for account blocks and proxy permissions are different. User shouldn't be displayed "your account is blocked" message in this case, they should be shown something like "you can not edit from this network"
"your account was unblocked but just the proxy you tried was blocked" - maybe. As I understand I was hit by global IP block ( https://meta.wikimedia.org/wiki/Global_blocks ) targeting range that included 176.12.107.132 - I see no blocks in https://commons.wikimedia.org/wiki/Special:BlockList?wpTarget=User%3AMateusz+Konieczny&blockType=&limit=50&wpFormIdentifier=blocklist
I was able to bypass block after contacting some special admins as explained (a bit murkily and not fitting mobile screen) in block message.
You could simply display the block message and people should be able to read and fix the problem (if the network is spooky, change network, if your account is gone, use web interface to submit an appeal). I am not sure if you have different api message for hard IP block (usually for OPs and worst of the worst user on the net) and the account block. Proxies also get blocked as if they're vandals.
At least, local blocks and global blocks have different block message, tho. And torblock also have different error iirc.
Hmm yes we can redirect user to web interface for ip block extemption thing too. I saw this kinds of messages at the time Wikipedia was blocked in Turkey and I had to use VPN, and it was different from "your account is blocked message". a- If we have such a distinct answers about blocks, we should inform user about the reason. We should exclusively create an issue for this task. b- If both has the same mechanism, this verifies "Relevant PR is merged but it appears to be not working." So we should fix relevant PR.
Summary:
We can inform user with a snackbar displayed at the bottom of each activities as "You are blocked from editing commons".
This can be done at our AuthenticadedActivity class (since all authenticaded classes extends it) to prevent rewriting same code again and again for all acitivites.