Per hobby, sto scrappando VC **giusto per creare uno scriptino in violent monkey per customizzarmi il sito** e ho riscontrato delle anomalie...Normalmente aprirei questo filo su >>>/t/ ma necessito avere quanta più utenza possibile per risolvere questo

Nome	70685
Email	Immagine sotto spoiler
Messaggio
File
Embed
Password	(Per rimozione del file)
Limiti:	Caratteri: 7200 Numero massimo file: 10 Upload massimo supportato: 20MB Lunghezza massima video: 5 minuti

File: 1732461220486.png (102.16 KB, 694x704, ClipboardImage.png)

Mimmo 24/11/24 (Sun) 16:13:40 No.167645

Per hobby, sto scrappando VC giusto per creare uno scriptino in violent monkey per customizzarmi il sito e ho riscontrato delle anomalie…

Normalmente aprirei questo filo su >>>/t/ ma necessito avere quanta più utenza possibile per risolvere questo enigma…

Su >>>/h/1 c'è in OP una foto in formato jpg. Nel catalogo, come ogni altra foto, viene creata una thumbnail il cui link riporta ad una foto in formato .png
E vabbè, qui credo ci sia il backend che fa il suo sporco lavoro per tenere gli scrapper come me lontani immagino. L'anomalia sta nel fatto che il sito restituisce negli header di risposta che il Content-Type è 'image/png'… Il problema è che se tratto il dato come png questo mi viene corrotto… Ad un'analisi più attenta, cliccando CTRL+I nella pagina https://vecchiochan.com/external/h/thumb/1606952242368.png mi viene riportato che il MIME è in formato .JPEG e trattandolo come tale l'immagine non mi viene corrotta

Vorrei capire perchè firefox mi dice una cosa, che a quanto pare è giusta, mentre l'header della risposta mi sfancula

Grazie in anticipo e buona giornata/fine settimana

Mimmo 24/11/24 (Sun) 16:17:05 No.167646

benvenuto nel fantastico mondo dei "programmatori" php

Mimmo 24/11/24 (Sun) 16:22:37 No.167647

>>167646
Bella merda, il problema è che tutto questo mi smerda di parecchio il parsing del catalogo, che per dirti, presenta immagini png come thumbnail per immagini jpg e viceversa. Problema risolvibile con uno swap di estensione se il parsing della foto va in merda…
Ma dal momento in cui content-type e estensioni coincidono lo swap non viene eseguito giustamente, e con foto come quella li si sminchia tutto quanto.

Mimmo 24/11/24 (Sun) 16:25:47 No.167648 RABBIA!

>>167647
>e con foto come quella li si sminchia tutto quanto

Ovviamente il caricamento della thumbnail esegue lo stesso procedimento del catalogo a pic chiusa… Ora non so se è possibile, ma avevo pensato di metr stippare i metadati del formato di una pic, ma non so se è possibile…

Mimmo 24/11/24 (Sun) 16:32:28 No.167649

>>167645
Ma 'nfatti i browser non si fidano più dell'indicazione MIME (per evitare che il server sfrutti una vulnerabilità di una libreria del browser), guardano direttamente il contenuto del file.

Mimmo 24/11/24 (Sun) 16:37:28 No.167651

File: 1732462648057-0.png (88.38 KB, 570x512, ClipboardImage.png)

File: 1732462648057-1.png (35.91 KB, 912x548, ClipboardImage.png)

File: 1732462648057-2.png (80.99 KB, 680x620, ClipboardImage.png)

>>167649
Un'altra infamità è picrelata
Dove il json, mi restituisce nel catalogo che il formato originale è .png (seconda picrel), il file originale è .png, se faccio il controllo con CTRL+I mi dice che è .JPEG… Qui nemmeno lo swap dell'estensione mi salva, perchè se la cambio nell'URL mi ritorna 404 perchè la risorsa non esiste con quell'estensione… Ma che cazzo di ritardo mentale ha il backend? E si! Sta cosa accade pure su Rete4!

Mimmo 24/11/24 (Sun) 17:02:03 No.167658

File: 1732464122228.png (16.39 MB, 3024x4032, ClipboardImage.png)

>>167651
Mah, io sono del parere che le immagini di una imageboard andrebbero tutte convertite in JPEG al momento dell'upload.

Webp e webm sono standard proprietari di Google (motivo per cui non li ha implementati quasi nessuno, a parte i browser e le utility di conversione).

Per esempio, perché diavolo questo PNG non viene convertito in GEI PEGGO ma ti fa sciroppare megabaite e megabaite di daunlode se clicci il thamboniello?

Mimmo 24/11/24 (Sun) 17:08:07 No.167660

File: 1732464487746.png (552.95 KB, 1920x1034, ClipboardImage.png)

>>167658
Concordo, comunque a questo punto mi faccio arrivare i dati di una pic in format "RAW" e mi conviene controllare i valori dei primi 10 byte dato che come dice >>167649 meglio non fidarsi del MIME nelle response…

Mimmo 24/11/24 (Sun) 20:00:15 No.167689

>>167651
In bocca al lupo ad implementare formati con codecs che un normale browser non prevede

Mimmo 24/11/24 (Sun) 20:57:02 No.167693

File: 1732478222828.jpg (108.56 KB, 800x583, osteosarcoma.jpg)

>>167689

Il suo compito è solo riconoscere il formato del file, per poi decidere se è visualizzabile o no (whitelisting: "ammetto solo png jpg mp4 webm")

Se proprio non riesce a farlo leggenedo i primi 10+ bytes, può sempre chiedere a ```/usr/bin/file``` (nella man page spiega tutto), che fra l'altro può anche dare in output il vero mimetype

Mimmo 24/11/24 (Sun) 20:58:43 No.167694

File: 1732478323788.jpg (124.58 KB, 938x1024, out of memory.jpg)

il backend sarà stato scritto in fretta e furia una domenica sera durante le partite

pic rel82

Mimmo 24/11/24 (Sun) 21:25:23 No.167696

File: 1732479923558.png (460.89 KB, 1920x1080, ClipboardImage.png)

>>167693
La realtà dei fatti è che sono arrivato a leggere solo il primo byte, dato che ogni file inizia SEMPRE con gli stessi 8 bit in base all'estensione. Nel caso di JPG è sempre 255, 137 per png e così via

>inb4 ma io leggo FF e 89
Si brutto demente, sono in HEX non in DEC

Ora il problema è che non riesco ad ottenere la thumbnail delle .gif che a volte vengono "rifatte" dal backend o in png o in jpeg senza ovviamente capirne il criterio. Il cazzo di guaio è che non ho modi di costruirmi il file dato che anche qui il mime della risposta da png ma in realtà il ricchione è in .gif ….

Pic allegata non generata da IA trovata nei meandri dell'internette

Mimmo 24/11/24 (Sun) 22:00:50 No.167705

>>167696
No ho capito nulla, ciaooo

Mimmo 24/11/24 (Sun) 23:09:33 No.167719

>>167658
Non sono proprietari handicappato

Mimmo 24/11/24 (Sun) 23:12:16 No.167720

>>167705
Io ho capito.
Studia di più

Mimmo 24/11/24 (Sun) 23:26:50 No.167722

Che tristezza l'informatica. Ma non potevate studiare matematica?

Mimmo 25/11/24 (Mon) 01:18:25 No.167726

>>167720
Dicci cosa c'è da capire. Che anon è il solito rotto di culo?

Mimmo 26/11/24 (Tue) 15:27:12 No.167917

>>167722
Tra fare il programmatore, il tecnico informatico, il magazziniere, fare le pulizie, e lavorare nella GDO in un supermercato, quale considereresti peggiore come lavoro?

Mimmo 26/11/24 (Tue) 16:42:50 No.167928

File: 1732635770087.jpg (176.71 KB, 1080x1221, 64oz2t12r5791.jpg)

>>167917
Quello in cui non ti pagano.

Mimmo 26/11/24 (Tue) 21:11:49 No.167972

File: 1732651909604.png (1.88 KB, 128x128, ClipboardImage.png)

Adminiello ma porco il cazzo, come è possibile che né nei thread né nel catalogo non c'è una cazzo di flag che indica se l'immagine è sotto spoiler o meno? È una info che ha solo il backend dato che nel json non c'è la chiave 'spoiler'. Per cui la thumbnail di un'immagine sotto spoiler è inesistente perchè il backend la rimpiazza con una foto dello spoiler che è di dimensione 128x128. La dimensione è l'unico modo per determinare se un file è spoiler o meno. Porco dio!

Mimmo 26/11/24 (Tue) 21:15:55 No.167974

File: 1732652155610.png (67.82 KB, 457x896, ClipboardImage.png)

>>167972
Cioè, che cazzo

Mimmo 26/11/24 (Tue) 23:15:56 No.167998 RABBIA!

6 TRPP AUTISTA ZIO

Mimmo 27/11/24 (Wed) 15:59:08 No.168126

>>167998
Vaffanculo

Mona 27/11/24 (Wed) 16:09:36 No.168130

Lol gli handicappati

Mimmo 27/11/24 (Wed) 16:25:26 No.168143

File: 1732721126703.png (Immagine sotto spoiler, 38.68 KB, 128x128, Immagine.png)

>>168130
Qui di handicappato c'è solo il backend che non da info se una pic è spoiler o meno. Si può solo ricavare "parzialmente" dalla dimensione della thumbnail che in media è 128x128 come pic allegata, ma potrebbe trattarsi anche di una foto non in spoiler. Un modo per determinare se una pic è spoiler è inviare una request all'url della thumb per ogni file supportato dalla IB (quindi su per giù una decina) e controlloare se le richieste danno 404 o 200. Di sicuro è un modo buono per capire se la pic è in spoiler, ma è troppo autistico e manda decisamente troppe richieste…

Suggerimenti alternativi?

Mimmo 27/11/24 (Wed) 17:23:37 No.168152

>>167645
Approfitto per chiedere agli esperti del filo, vecchiochan è stato creato da 0 o dietro c’è un chan framework?

Mimmo 27/11/24 (Wed) 17:33:22 No.168157

>>168152
Il backend è questo
Un fork di vichan
https://github.com/fallenPineapple/NPFchan/tree/master

Mimmo 27/11/24 (Wed) 17:37:20 No.168158 RABBIA!

>>168152
Comunque se volevi sapere se una roba del genere si può fare da 0, la risposta è si!

È un progettino che perfino un Esposito porterebbe all'esame di maturità all'itis

Mimmo 27/11/24 (Wed) 17:45:20 No.168161

>>168158
Quello non lo metto in dubbio, ma vuoi mettere tirare su un sito cosi in un'ora?

Mimmo 27/11/24 (Wed) 17:52:47 No.168165

>>168161
Anche meno, fai conto che non c'è un vero e proprio DB dietro. Credo che in mezz'ora qualcosa di funzionate la fai, a patto che scegli un linguaggio per il backend buono e con cui hai esperienza nonostante reputi il php una buona scelta per certi aspetti.

Credo che in 10 minuti da zero con python + flask + request riuscirei nell'impresa

Mimmo 27/11/24 (Wed) 17:55:19 No.168167

>>168165
Aspe quindi quel framework non ha backend? Allora quello lo hanno fatto da zero

Mimmo 27/11/24 (Wed) 18:00:21 No.168168

>>168167
Quello che tu chiami framework, è il backend in realtà. Un framework può essere il sopracitato flask, django e simili.

Ma capisco che negri dell'informatica non si nasce per cui è normale scrivere roba a cazzo

Mimmo 27/11/24 (Wed) 18:01:59 No.168169

File: 1732726919694.png (75.72 KB, 1441x908, ClipboardImage.png)

>>167974
>>167972

Cmq ecco come viene gestito lo spoiler

Mimmo 27/11/24 (Wed) 18:16:04 No.168179

File: 1732727764635.jpg (44.54 KB, 687x539, IMG-20241127-WA0014.jpg)

>>168169
LMAO spanate e dilatate informatici del cazzo! Che poi perfino gli endpoint di diochan hanno lo spoiler nel giasone

Mimmo 27/11/24 (Wed) 18:47:51 No.168187 RABBIA!

>>168179
Questa cosa mi ha fatto incazzare, bravo!

Mimmo 27/11/24 (Wed) 18:54:35 No.168190

>>168168
Ok quindi hanno fatto una fork del frontend e scritto un backend da 0, corretto?

Mimmo 27/11/24 (Wed) 18:56:45 No.168191

>>168190
No, una fork del backend che è stato modificato per X esigenze.

Diciamo che 'scritto da zero' è il backend forkato

Mimmo 27/11/24 (Wed) 19:53:03 No.168203

File: 1732733583030.png (93.04 KB, 886x886, 1702509016223426.png)

>>168191
Forchetta

Mimmo 27/11/24 (Wed) 20:19:26 No.168207

>>168191
ma come può essere scritto da zero se è forkato?

Mimmo 27/11/24 (Wed) 20:36:09 No.168209

>>168207
Di base no, altrimenti sarebbe un progetto a se stante. Di solito nei fork vengono fatte delle modifiche ad hoc per altri tipi di casi d'uso o in altri casi delle aggiunte ad un sistema che di per sé funziona ma con delle funzionalità che prima non erano presenti…

Cmq ho fatto richiesta ad adminiello su

>>>/jira/452

direi di farci sentire senza rompere troppo i coglioni dato che come ho scritto nel post, questa semplice modifica retroattiva consentirebbe a VC di essere implementato anche su altri tipi di reader che non siano il solito browser