404, które nie mówiło prawdy o pliku

Ciao! 🇵🇱🇮🇹

18 lipca link do pliku działał u mnie w przeglądarce i nigdzie indziej na świecie.

Przez chwilę byłem pewien, że winny jest odbiorca linku, nie link.

Lecimy z tematem 🚀

Publiczny link do prywatnego repo, który nie istniał

18 lipca chciałem wysłać karuzelę PDF na LinkedIn przez Buffer, dla Akademii Negocjacji. Research już wcześniej pokazał, że dokument wielostronicowy dostaje lepszy zasięg niż zwykły obrazek. Buffer przyjmuje jednak tylko publicznie dostępny URL do pliku, nie binarny upload. Gotowy PDF miałem już w marini-hub, moim prywatnym repozytorium na GitHubie. Pomyślałem: wystarczy link w formacie raw.githubusercontent.com, po co zakładać kolejne konto na jakimś zewnętrznym hostingu.

Skopiowałem URL według wzorca raw.githubusercontent.com/{user}/{repo}/main/{ścieżka} i otworzyłem w przeglądarce. Zalogowanej, oczywiście, na moje konto GitHub. Plik pokazał się bez żadnego problemu. Wkleiłem ten sam URL do Buffera. 404. Plik jakby nie istniał.

Sprawdziłem jeszcze raz, tym razem przez curl, bez żadnego logowania, z linii komend. To samo: 404. A git log na tym pliku pokazywał commit, branch main, wszystko na miejscu. Więc plik tam był. Tylko nie dla Buffera.

Powód okazał się prosty, jak już go znalazłem. raw.githubusercontent.com nie ma trybu „publiczny link mimo prywatnego repo”. Dla prywatnych repozytoriów wymaga uwierzytelnienia zawsze, bez wyjątków, niezależnie kto pyta. Mój dostęp z przeglądarki działał tylko dlatego, że akurat byłem zalogowany do GitHuba w tej samej sesji, w tej samej karcie. Buffer nie ma jak się zalogować za mnie. Dla niego repo po prostu nie istniało, tak jak dla każdego innego serwisu z zewnątrz.

Dopisanie tokena do URL-a rozwiązałoby to technicznie. Ale wysyłanie tokena z dostępem do prywatnego repo do zewnętrznego API to zły pomysł, niezależnie od okoliczności. Zamiast tego założyłem osobne, publiczne repozytorium tylko pod pliki, które muszą być fetchowalne z zewnątrz. Bez kosztu, w pełni pod moją kontrolą.

404 nie zawsze znaczy, że pliku nie ma. Czasem znaczy, że dostęp masz Ty, a serwis po drugiej stronie nie.

🛠️ Narzędzie

gh repo view --json isPrivate

Jedna komenda GitHub CLI, która od razu mówi czy repozytorium jest publiczne czy prywatne, bez klikania w ustawienia na stronie. Sprawdzam ją teraz odruchowo, zanim jeszcze raz spróbuję użyć raw.githubusercontent.com jako darmowego hostingu pliku dla zewnętrznego serwisu. Zero zgadywania. Wynik jest jednoznaczny, w przeciwieństwie do komunikatu 404, który potrafi znaczyć zupełnie różne rzeczy.

cli.github.com

🌍 Ze świata

• America’s top cyber-defense agency left a GitHub repo open with passwords, keys, tokens. Odwrotność mojego przypadku. Ja przez pół roku mogłem mieć problem z za mało publicznym linkiem, CISA przez ten sam czas miało problem z za bardzo publicznym repozytorium haseł.

• LinkedIn adds a button to report AI-generated ‘slop’. Ciekawe, ile z tych zgłoszeń trafi w treści, które przeszły dokładnie taką checklistę anty-AI jak ta, przez którą przechodzi każdy numer tego newslettera.

• Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data. Mój problem był o jeden krok za mało publiczny. Ten opisuje dokładnie odwrotny błąd, wykorzystany celowo przez kogoś, kto wiedział co robi.

😄 Na koniec

Repozytorium, które miało być prywatne, i repozytorium, które miało być publiczne. Skończyłem z jednym z każdego, zamiast pomylić je ze sobą.

Jeśli ktoś w Twoim otoczeniu powinien to przeczytać, prześlij mu ten numer. To najlepsza forma wsparcia.

A jeśli wolisz wesprzeć bezpośrednio: postaw mi kawę.