How necessary is it to totally restrict readers with suspicious IPs? This feature is for readers, any reader can get so IP. The IP problem will only get worse. Perhaps it will be enough to request a captcha (only for those coming from the sidebar with such IP) or remove this restriction. See also meta:Talk:No open proxies/Unfair blocking, [1][2][3], en:Wikipedia:Blocking IP addresses#Problems and solutions. @OVasileva (WMF), @Ladsgroup, @Krinkle. @Pppery, started a new topic here, as you advised
Extension talk:UrlShortener
While I understand, the short urls have potential to become abuse vectors, e.g. to be used to disclose someone's identity. That's why it's not allowed to create a short url while blocked. The focus should be to reduce unfair block of IPs tbh.
I’m not sure that this helps in any way specifically for Wikimedia sites, where statistics and data on those who used the link are not provided for users.
I’m not sure that the fight against unfair blocking will lead to anything serious: this problem may not be solved for years, IPs are now being resold very actively. Moreover, since IP masking is planned, the blocking will only get stronger, in my opinion. A separate problem, as far as I understand, is that many people use proxies regularly.
In the abstract, preventing blocked users from performing on-wiki actions is a reasonable anti-abuse measure. I don't think you'd disagree with that?
Anyways, agreed with Ladsgroup here. The problem is that "blocked users" includes a number of people who (presumably) have done nothing wrong and are just being blocked for their IP address, VPN, etc. That is the central issue that needs to be solved and trying to address it feature-by-feature is going to be a mess and endless rehashing of the same discussion. Adding workarounds just reduces the incentive and pressure to solve it properly.
The key difference is that it is a tool for readers.
Readers are generally not restricted no matter what IP they have or whether they use a VPN. Besides, they won't even understand what it is
It redirects to my home page (<code>example.com/</code>) instead of the specific wiki page. The full URL of that wiki page is stored correctly in the database, just like the others before and after it. It doesn't go to the "Sorry, the URL you are looking for has not been found." error page.
The only thing that's notable is that it's ID is 100, but I can't imagine that being the cause.
I'll keep thinking about it, but if you have any ideas that would be great.
It was my own fault. I'd messed up an .htaccess redirect ages ago and hadn't noticed.
I had to change
#Same for short.uk/a as it doesn't get set automatically by the extension
RewriteRule a http://www.long.co.uk/ [R=301,L]to
RewriteRule ^a$ http://www.long.co.uk/ [R=301,L]How can I change this? Thanks.
This is on purpose, it saves one character in the database. UrlShortener should be transforming it back to HTTPS on output, is that not the case?
Yes that seems to work fine! (I only noticed the http when checking a short URL that refuses to redirect properly for some reason.)
Not a UrlShortener question as such, but is there something I am missing in LocalSettings.php that would obviate the need for the second 301 below?
Status code Scheme URL 301 https https://www.short.uk/xyz 301 http http://www.long.co.uk/index.php?title=Special:UrlRedirector/xyz 301 https https://www.long.co.uk/index.php?title=Special:UrlRedirector/xyz 200 https https://www.long.co.uk/Pagename
Is this a new thing? I upgraded from MW 1.34 to 1.35.8 today, and did a "git pull" on this extension. That broke the site but "git checkout REL1_35" fixed it.
The URL shortener used to work as part of the dropdown menu in the Foreground skin. Now when you click "get shortened URL" it redirects to the special page first and you have to click another button.
Is there any way of getting back to the old way of doing things? Thanks.
Sorry for such a quick rubber duck solution. But "git checkout REL1_36" makes the nice behaviour return!
Hello, everyone
If user set custom URL in short domain it looks like UrlShortener requires new parameters
First request feature (Set Start Short URL)
For example if user set 5 integer number length or 3 integer number length short URL for long URL, default setting extension begin 1 integer number length and 2 to 3 and etc
Second request feature (Set Short URL manually)
But user want short URL begin from custom address.
But also user if want set short URL manually (not random) UrlShortener extension not supported yet.
For example:
Start and first Short URL: w.wiki/50000
Second Short URL: w.wiki/50001
Third Short URL: w.wiki/50002
.
.
.
End Short URL: w.wiki/99999
or
Start and first Short URL: w.wiki/aaaaa
Second Short URL: w.wiki/aaaab
Third Short URL: w.wiki/aaaac
.
.
.
End Short URL: w.wiki/zzzzz
Third request feature (Set Forbidden URL characters)
But add setting parameters for forbidden URL characters address by regex rule.
I've set up a script that makes use of the API to shorten URLs right from a spreadsheet, and I was surprised to find that the $wgUrlShortenerAllowedDomains is not tested then. I could shorten just about anything as long as it was a valid URL.
Just added a bug https://phabricator.wikimedia.org/T297382
This is what appears:
[c99ad0719e66fffd1396db68] Caught exception of type Wikimedia\Rdbms\DBQueryError
Please see How to debug for obtaining the full error message, what you provided really isn't enough to go on.
Per discussion at gerrit:513960, I have created a draft of a help page here on mediawiki at User:DannyS712/Help:UrlShortener. Contributions are welcome.
I get the following error when trying to download this extension:
No such extension "UrlShortener".
Unable to fetch extension list!
Nicole Sharp (talk) 17:51, 6 June 2019 (UTC)
It seems to work now. (Using the default version selected). Perhaps it was just a temporary problem?
Copied from -core;
14:12 (xSavitar) I'm not sure but do we think UrlShortener extension could come in handy for codesearch links? 14:13 (xSavitar) Usually, CS links are long and putting them in commit messages is not so cool per wrapping 14:13 (xSavitar) Maybe the shortener can support codesearch links? Maybe Ladsgroup can throw a word or two
This could really come in handy as CS links are usually long. Cc @Ladsgroup
That should be addressed as part of m:Talk:Wikimedia_URL_Shortener#Toolserver It's up to core platform and security team to approve it and then it's just a config change.
Okay, thanks!