Ostatnio stworzyłem dla znajomego pewną wtyczkę do WordPressa, która w momencie wystąpienia pewnych, z góry określonych warunków dokonywała automatycznej modyfikacji linków znajdujących się na stronie (konkretnie w artykule/wpisie), według ustalonych założeń. Przy tej okazji kolega zauważył, że w niektórych linkach pojawia się atrybut „noopener”. Zresztą nie tylko on (atrybut, nie kolega).
Spis treści w artykule
Link bez otwieracza, czyli rel=”noopener”
WordPress od wersji 4.7.4 do niektórych linków tworzonych w postach i na stronach dodaje atrybut „noopener”, czyli… brak otwieracza. Przynajmniej jakby chcieć to tłumaczyć bezpośrednio/dosłownie. Atrybut ten jednak z otwieraczem do kapsli nie ma nic wspólnego, a po prostu dodatkowo chroni osobę odwiedzającą naszą stronę, gdy ta kliknie link do złośliwej strony. Oczywiście celowo byśmy do niej nie linkowali, ale domeny co chwilę zmieniają swojego właściciela, więc równie może z tym być.
Domyślnie linki – nie tylko w WordPressie – otwierają się w tym samym oknie (w tej samej karcie), w którym znajduje się strona z linkiem. Taki link wygląda np. tak:
<a href="https://webinsider.pl/">Zapraszamy na Webinsider.pl</a>W tym przypadku nie został dodany ani atrybut „rel”, ani tym bardziej jego parametr „noopener”. Sytuacja się zmienia, gdy podczas dodawania linku zaznaczymy, że ma on otworzyć się w nowym oknie (karcie):
<a href="https://webinsider.pl/" target="_blank" rel="noopener">Zapraszamy na Webinsider.pl</a>W tym przypadku mamy atrybut „target” o wartości „_blank”, co określa, że link ma zostać otwarty w nowym oknie (w nowej karcie). Ale oprócz tego mamy jeszcze atrybut „rel” o wartości „noopener”. I nie jest to przypadek, że te dwie pary działają obecnie w duecie.
Strony internetowe są coraz bardziej rozbudowane, pełne kodu JavaScript, który z jednej strony sprawia, że na takich stronach możemy robić coraz więcej, niczym w normalnych programach uruchamianych na komputerze. Ale z drugiej strony, oznacza to większe ryzyko związane m.in. z bezpieczeństwem.
W pewnym momencie zorientowano się, że korzystając z „window.opener.document” w połączeniu z otwieraniem linków w nowym oknie można za pomocą docelowej strony zmienić zawartość strony, na której znajdował się link. Taka zmiana nie dotyczy bezpośrednio strony na serwerze, a „tylko” strony wyświetlanej w przeglądarce danego użytkownika. I tak w uproszczeniu narodził się „noopener”, który ma przed czymś takim chronić.
Choć nie wiem, czy lepszym wyjściem nie byłoby dodawanie do linków czegoś podobnego w sytuacji, gdy chcemy umożliwić taka zmianę, bo jest to zdecydowanie sytuacja rzadziej spotykana (bardziej specyficzna) niż zwykły link, nawet jeśli otwierany w nowym oknie (nowej karcie).
Do kompletu: „noreferrer” i „nofollow”
Skoro o WordPressie wspomniałem, to – jeśli pamięć mnie nie myli – wraz z „noopener” do linków zawitał jeszcze „noreferrer” (kwestia Firefoxa, który – w tamtym okresie – nie wspierał „noopener”), co od razu wywołało liczne burze, zwłaszcza na stronach związanych z pozycjonowaniem (SEO). Zaczęły pojawiać się głosy, że linki tak oznaczone mogą być złe dla SEO, bo nie będą „przekazywać mocy” do linkowanej strony. Co raczej nie miało(by) znaczenia dla strony linkującej, a dla strony linkowanej. Ostatecznie chyba nikt tego nie udowodnił, ale z WordPressa zniknęło automatyczne dodawanie „noreferrer” do linków.
Zamieszanie (łagodnie mówiąc/pisząc) wzięło się z tego, że niektórzy skojarzyli „noreferrer” z „nofollow”, co w połączeniu ze swoistą niewiarą osób zajmujących się pozycjonowaniem w zapewnienia Google musiało wywołać gorące dyskusje. A wiadomo, że SEO zapleczami stoi, a zaplecza linkami…
W każdym razie:
- noopener – strona do której linkujemy, nie może mieć wpływu na zawartość nasze strony (okna/karty ze stroną, na której znajduje się link), czyli nie może podmieniać jej zawartości
- noreferrer – brak przekazywania do docelowej strony adresu strony odsyłającej/linkującej (nagłówek HTTP), czyli strona docelowa nie wie, z jakiej strony do niej przyszliśmy, skąd nastąpiło odesłanie
- nofollow – tak oznaczamy link do strony, której nie chcemy „przekazać mocy” naszej strony, co jest zalecane przez Google m.in. w przypadku linków płatnych, np. w artykułach sponsorowanych (brak tego tagu sprawia, że link jest „dofollow”, a wbrew temu, co wielu myśli, również „zawodowców”, sam tag „dofollow” jako taki nie istnieje)
Nie są to jedyne wartości, jakie może przyjąć atrybut „rel” linku, ale pozostałe raczej nie mają znaczenia w kontekście tego artykułu.
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.
Dumny przyjaciel swoich psów :-)
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
Czyli tłumacząc na ludzki:
noreferrer – nie chcemy by strona docelowa wiedziała o nas
noopener – nie chcemy by strona docelowa miała wpływ na nas
nofolow – nie chcemy by my mieliśmy wpływ na stronę docelową
Można to i tak przedstawić, może (miejscami) zbytnio uproszczone, ale podejrzewam, że dla wielu taka forma może być prostsza do przyswojenia. Dzięki :-)
PS. Czemu ostatnio (chyba od czasu jak się bawisz kampaniami), po zostawieniu komentarza wywala mnie na 404? (końcówka url ?utm_source=404&utm_medium=Redirect&utm_campaign=404). Dla pomocy przychodzę w RRS z takimi parametrami (?utm_source=RSS&utm_medium=RSS&utm_campaign=RSS&utm_content=RSS post title)
Zacznę od tego, że dzięki za informacje, oraz sorki, że mogło Cię trochę „przyspamować” powiadomieniami o nowym komentarzach, ale musiałem zrobić kilka testów by odszukać winnego. Tagi „utm” w tych linkach są od bardzo dawna, więc od razu postanowiłem poszukać czegoś innego. Niedawno ustawiłem wtyczkę Bloom od Elegant Themes by po dodaniu komentarza pojawiało się zaproszenie do zapisania się do naszego Newslettera. I jak się okazało, tu był problem.
Po dodaniu komentarza wtyczka modyfikuje adres URL, by dodać swój znacznik, który powoduje „odpalenie” okienka z formularzem. Problem tylko w tym, że przy okazji kasuje część adresu, zostawiając tylko główny adres strony (domenę) i dodając swój parametr, który jest nieprawidłowo wstawiony. Bo zaczyna się od & (tak zaczynają się kolejne parametry) zamiast ? (pierwszy parametr):
Zaraz wyśle im zgłoszenie, niech to sprawdzą.
PS. A możesz włączyć/poprosić o filtr, który by nie przekierowywał jak ktoś jest z RSS. Bo jeśli cię już subskrybuję w taki sposób to raczej nie ma sensu mnie zapraszać do maillisty. Miałem, to pytać we wpisie o liście, ale jakoś nie miałem okazji.
PS2. Czy cache/cooks mógł by zapamiętywać moje dane, bym nie musiał za każdym razem wpisywać nick i mail?
Kanał RSS to „tylko” powiadomienia o nowych wpisach (dla mnie najwygodniejsza chyba forma), czego aktualnie nie ma w newsletterze (ale pojawiła się możliwość zapisania również do powiadomień o nowych wpisach, start zapewne niebawem, jak tylko fajnie to zautomatyzuje), w którym są za to inne rzeczy. Wprawdzie od jakiegoś czasu był on odstawiony na bok, trochę zapomniany, ale w 2018 ma to się zmienić.
Zobaczymy co mi odpiszą z supportu na ten błąd (jeszcze go sprawdzę w środowisku testowym), bo nie przepadam za modyfikowaniem wtyczek. Czasem to robię, ale wtedy muszę wdrażać dodatkowe mechanizmy, by taka modyfikacja przeżyła aktualizację wtyczki.
Co do wstępnego wypełniania danych, to muszę zobaczyć, jak można by to ewentualnie zrobić, bo może wystarczą „drobne prace”, a być może wymagane modyfikacje będą zbyt rozległe, i co za tym idzie, prościej będzie np. zezwolić na zakładanie kont na stronie. Jest to trochę ryzykowne (eskalacja uprawnień się zdarza), ale na pewno by rozwiązało problem. No i zawsze to też dodatkowe połączenie z czytelnikiem… :-)
No i znalazłem przyczynę błędu 404. Okazuje się, że w pewnych okolicznościach gryzą się 2 wtyczki od Elegant Themes – Monarch (media społecznościowe) i Bloom (łapanie adresów). Mógłbym wprawdzie całość sprowadzić do 3 punktów „po ludzku”, ale jest spora szansa, że problem występuje u innych (odpowiednie wyszukiwanie w Google znajduje trochę zindeksowanych adresów z błędem ;-)), to jutro pewnie zrobię o tym wpis. Zawsze większa szansa, że trafią na niego zainteresowane osoby, niż tutaj, wśród komentarzy… ;-)
Heh, a ja nie używałem jeszcze „noopener”. Teraz na pewno będę. :) Dzięki za info!
Ogólnie jak popytałem po znajomych, i to takich „bardziej technicznych” niż „przeciętny internauta” to jest z tym średnio. Dlatego wolałbym – zwłaszcza po pojawieniu się ataków – by działało to raczej na zasadzie opt-out, czyli domyślnie ingerencja w stronę źródłową (to co w przeglądarce) jest blokowana, a tagiem można ewentualnie na to zezwolić – bo są sytuacje, gdy takie działanie jest wymagane/potrzebne. Zwłaszcza, że – choćby w przypadku WordPressa – dotyczy to tylko relatywnie nowych linków, a raczej nikt teraz ręcznie tego nie będzie zmieniał wstecz, chyba, że na jakiejś małej stronie, z tylko kilkoma linkami…
Zgadzam się w 100%, że noopener powinien być opcją domyślną.
Co do kontroli referrer można mieć dużo większą kontrolę nad tym za pomocą nagłówków. Trzeba być ostrożnym, bo łatwo popsuć np. GA
https://wiki.mozilla.org/Security/Guidelines/Web_Security#Referrer_Policy
Dzięki za link, może komuś się przyda, i tak jak piszesz – zalecam rozwagę. Zwłaszcza jakby ktoś zabrał się również za rodzinkę „origin”. Właściwie to temat na oddzielną opowieść (artykuł), bo można chcąc dobrze, nieźle sobie uprzykrzyć życie. Zwłaszcza, jak miksujemy skrypty np. miedzy swoimi domenami…
A co do „noopener” to w kontekście „window.opener.document” można by chyba uznać to za podatność, tylko tym razem zdecydowano się nie na jej odgórne (domyślne) załatanie, a stworzono mechanizm pozwalający zabezpieczyć użytkownika (bo serwer jest bezpieczny) dla każdego linku oddzielnie. Może wydawać się dziwne, ale można odnieść wrażenie, że uznano, że opcja „Opt-In” będzie w tym wypadku lepsza, niż „Opt-Out”. Na pewno dla deweloperów niektórych rozwiań, które mogłyby przestać działać, i wymagały by pilnej aktualizacji. Ja uważam, że powinno jednak być odwrotnie…
Czy można używać wszystkie 3?
(rel=”noopener noreferrer nofollow”)
Czy tylko jeden wybrany?
Można.
Dziękuję za szybką odpowiedź.