Recenzii pentru Web Archives
Web Archives de Armin Sebastian
Recenzie de către KirkH420
Evaluat(ă) cu 4 din 5 stele
de KirkH420, 4 ani în urmăIt works to some extent, I like it's ability to open all the different web archives with one click.
There is a bit of an issue with some archives. For URLs: When I click on an URL to a Microsoft.com out-dated page, the Wayback Machine will take me to Microsoft's Error404 landing page.
This URL for example:
https://www.microsoft.com/en-us/download/details.aspx?id=45885
When passed to this add-on, the Wayback Machine converts it to this page:
https://web.archive.org/web/20220328035922/https://www.microsoft.com/en-us/download/404Error.aspx
*It's landing on a Wayback Redirect page. After 5 seconds, the page gets redirected to another page.
We can see in the date is /2022-03-28-03:59:22/ and this is one of the newest snapshots created by the Archive. It's unfortunate, but The Wayback Machine continues to create snapshots of these 404 pages.
So someone might say, why don't you just use the Wayback Date-toolbar to turn back to an older date? The problem is, since your tool is finding the newest snapshots, it's returning these 404 pages. This changes the URL that we're searching for.
The API docs for the Wayback Machine says "timestamp is the timestamp to look up in Wayback. If not specified, the most recenty available capture in Wayback is returned."
The correct way to use the API is to create a link like this:
http://archive.org/wayback/available?url=https://www.microsoft.com/en-us/download/details.aspx?id=45885×tamp=20010101
*This will return a .json that contains a working "closest snapshot" URL and you can click on it.
It appears that this add-on is not using the API but is trying to manipulate URLs instead. This wont work well.
If you add the "×tamp=20010101" key, it will enable the "Return closest snapshot to the date 2001-01-01" rather than return the newest available snapshot. The downside is, you'll need to write something that will handle the .json API return data. (which shouldn't be very hard)
Doing it that way will ALWAYS return a website. Not those Error404 landing pages.
There is a bit of an issue with some archives. For URLs: When I click on an URL to a Microsoft.com out-dated page, the Wayback Machine will take me to Microsoft's Error404 landing page.
This URL for example:
https://www.microsoft.com/en-us/download/details.aspx?id=45885
When passed to this add-on, the Wayback Machine converts it to this page:
https://web.archive.org/web/20220328035922/https://www.microsoft.com/en-us/download/404Error.aspx
*It's landing on a Wayback Redirect page. After 5 seconds, the page gets redirected to another page.
We can see in the date is /2022-03-28-03:59:22/ and this is one of the newest snapshots created by the Archive. It's unfortunate, but The Wayback Machine continues to create snapshots of these 404 pages.
So someone might say, why don't you just use the Wayback Date-toolbar to turn back to an older date? The problem is, since your tool is finding the newest snapshots, it's returning these 404 pages. This changes the URL that we're searching for.
The API docs for the Wayback Machine says "timestamp is the timestamp to look up in Wayback. If not specified, the most recenty available capture in Wayback is returned."
The correct way to use the API is to create a link like this:
http://archive.org/wayback/available?url=https://www.microsoft.com/en-us/download/details.aspx?id=45885×tamp=20010101
*This will return a .json that contains a working "closest snapshot" URL and you can click on it.
It appears that this add-on is not using the API but is trying to manipulate URLs instead. This wont work well.
If you add the "×tamp=20010101" key, it will enable the "Return closest snapshot to the date 2001-01-01" rather than return the newest available snapshot. The downside is, you'll need to write something that will handle the .json API return data. (which shouldn't be very hard)
Doing it that way will ALWAYS return a website. Not those Error404 landing pages.
334 de recenzii
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 18285082, 6 zile în urmă
- Evaluat(ă) cu 5 din 5 stelede BaraShiro, 11 zile în urmă
- Evaluat(ă) cu 5 din 5 stelede ilovemikael, 20 de zile în urmă
- Evaluat(ă) cu 5 din 5 stelede Jatila, 23 de zile în urmă
- Evaluat(ă) cu 5 din 5 stelede GnarlyCmdr, 24 de zile în urmă
- Evaluat(ă) cu 1 din 5 stelede Utilizator Firefox 19720321, 2 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Dan, 2 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 17451381, 2 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Jalewood, 3 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 15958710, 3 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Java, 3 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 19611278, 3 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 19604848, 4 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Anonymous, 4 luni în urmăVery useful. Information should be free for all.
- Evaluat(ă) cu 5 din 5 stelede أبوعلي, 5 luni în urmă
- Evaluat(ă) cu 4 din 5 stelede Ugarov, 7 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 18960744, 7 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Deo, 7 luni în urmă
- Evaluat(ă) cu 1 din 5 stelede Kaqxar, 7 luni în urmăAlas it breaks login pages which use Cloudflare captcha!
I first thought that uBO and/or Privacy Badger are the culprit and disabled those, but then still could reliably reproduce the bug. Then I disabled *ALL* my extensions and enabled them one by one, meanwhile testing logging in. When I turned on Web Archives, login stopped working, I got an error message after entering my credentials and clicking the "I am a human" checkbox on the popup Cloudflare captcha.
Once I disabled Web Archives, login started to work again.
Mind you, this test was done with uBO and PB still being disabled.Răspunsul dezvoltatorului
postat la 7 luni în urmăI don't see how this extension could break your login page, but if you'd open an issue on GitHub, we could debug the problem together by testing the same login page.
https://github.com/dessant/web-archives/issues - Evaluat(ă) cu 4 din 5 stelede dost, 8 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede frostbyte, 8 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 19173586, 8 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 19114790, 8 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 18905802, 8 luni în urmă
- Evaluat(ă) cu 5 din 5 stelede Utilizator Firefox 19145735, 8 luni în urmă