[Textlib] Újabb módosító javaslat

[Szabo Istvan]

On Wed, 6 May 2009, Nagy Imre wrote:

> > Ott érzem még kicsit sántának a dolgot, hogy aki nem saját MTA-val
> > rendelkezik, annak macerásabb lehet az egész.
>
> Pl: közhálós rendszeren meg se engedik saját MTA használatát.
> TextLib müködési modeljétől az ilyen visszaigazoló levlek lekezelése elég
> távol áll.

Ok, de azért csak le kell kezelni azt, hogy már "kiment" a levél.
Valahonnan meg tudomására is kellene hozni a TL-nek, hogy mi lett a
végeredménye.
Nem túl szerencsés újra és újra kiküldeni a megszünt e-mailre leveleket.
Persze könyvtárosokra is lehet hárítani, de ha lehet valamilyen szinten
automatizálni akkor tegyük.

Egyébként nem visszaigazoló levélről, hanem visszapattanórol - bounce -
beszéltem. A visszaigazolás kérésének valóban semmi értelme.


> Semmikép se szeretém hogy levél tartalomba keresgéljen egy robot, és a
> levél tartalom alapján bármit is csináljon. nagyon veszélyes!
> + se idő se pénz nincs rá

Akkor adni kell egy interface-t ahol ezt el lehet végezni, aki akarja - én
akarom.
Egyébként mi történik, ha hamisítanak egy levelet, miszerint xxx címre nem
lehetett kézbesíteni? TL-be inaktívvá válik az olvasó e-mail címe így
legközelebb nem küld neki e-mail-t, hanem postán kapja meg.
Tehát személyes adatban változás nem történik, +infóhoz a "támadó" nem
jut.


> > 1. Kézi indításu e-mail felszólító indítása, vagy időzítő indítja
>
> kölcsönzési lejárat előtti figyelmezttés mindenképp időzítő.
> Felszólítás nehéz történt.
> 1: Postai nálunk csak akkor megy ki, ha nyitva vagyunk. Email miért ne
> mehetne minden nap? hétvégén is?

Gondolom pont a visszapattanó levelek miatt, amit a dolgozónak kellene
kezelni. Arról nem is beszélve, hogy egy megkapott e-mail-re egyből
megpróbálhat reagálni és felháborodásában azonnal telefonon, márpedig
hétvégén nem veszi fel senki, így csak forr tovább - talán hétfőre
lecsillapodik...
Talán legyen opcionális, hogy figyelembe vegye -e a zárvatartási napokat
vagy sem?


> Kézi szerintem csak hibajavítás céljából.

Hogy mi célból és mikor használja azt majd eldönti a nép, a lényeg, hogy
legyen ;-)


> > 2. Levelek átadása MTA-nak (ami 1-2 órán belül vagy elküldi vagy
> > visszadobja, több napos próbálkozást kizárnám az MTA-ból)
>
> Idő töklényegtelen, MTA konfigurációjától függ. Sehogy nem tudod
> megváltotatni. Adott könyvtár feladata. Projktnek nem része.

Ne mondd, hogy nem része a levelek átadása MTA-nak, akkor hogy megy ki?
;-)

Saját MTA esetén simán megváltoztatom ;-)
Arról tényleg megfeledkezem időnként, hogy a többség nem saját MTA-t
üzemeltet. Ez esetben talán szóba jöhetne az Infoker mint relay, régebben
formmail révén rémlik hasonló, aki kérte.


> > 3. Ami visszajön, azt a hibakódnak megfelelően visszadnám a TL-nek, hogy
> > rögzítse  kézbesíthetetlenséget, esetleg okát.
>
> Nemlehet megcsinálni.

TL gateway a webes matatást is eljuttatja a TL-hez, gondolom mást is el
lehetne juttatni.


> > 4. Ami nem jön vissza 2 óra 10 perc mulva, azt úgy veszem elment (MTA
> > beállítás alapján), ezt is berügzítem TL-be.
>
> Szintén kuka.
> Ez nem a textlib feladata.

Az, hogy az MTA dolgait kezelje rendben, viszont interface-t kellene adni,
hogy ha akarom tudjak adatot szolgáltatni bele. Hogy milyen frontendet
teszek elé, az legyen az én bajom.
Csak mert ingyenes, ne küldözgessünk már összevissza leveleket.


> Plána egy rakás MTA-nál a kézbesítési visszaigazolás se jön. Egyszerűen
> nem küldi vissza.

Nem visszaigazolásról beszéltem, hanem visszapattanó levélről - bounce.


> > Így van és saját MTA esetén sokkal több lehetőség van.
>
> Márha a zinternet szolgáltató megengedi. Legjobb tudomásom szerint a
> t-online is bevezette a saját MTA tiltását. SPAM védelem okán..

Szerintem haszbálhatsz, ha a t-online a relay. Tény viszont, hogy a
hálózatukból kifelé smtp-t nem tudsz indítani.

Ehh, erről jut eszembe, hogy valóban gáz lehet a kézbesítés lekövetésével
:-( Megfeledkeztem arról, hogy hiába saját MTA, ha a tuloldal "csak"
relay, akkor átveheti kézbesítésre, de nem jelenti feltétlen azt, hogy
sikerül is neki... :-(
Nem egyszerű, át kell gondolni valóban..


> > Ennek egy részére megoldás a https, JS-t ki kellene hagyni a dologból -
> > szerintem
>
> Nem , https-t nem nagyon javaslom. Miért? Egyszerűen nincs pénzünk hiteles
> ssl tanusítványra.

HBONE hálózaton évi 10e 1db ssl tanusítvány.

> Tapasztaltam hogy mekkora gond a felhasználóknak a figyelmeztetésen
> túljutni. Mi ebből nem kérünk.

Egy sima http oldalon, ahol erre magyarázat, pár kép van talán segíthet a
saját kiállításu tanusítvány problémáján átjutni, ami ingyenes.
Ha az adobe oldalán IE-hez szeretnél flasht letölteni/telepíteni az
activeX miatt felső sáv jelenik meg, ami szintén beavatkozást igényel, ott
is "oktató" ábra látható, hogy hogyan járjon el, márpedig Ők nagyban
játszanak.
Arról nem is beszélve, hogy egyre több hasonló https oldallal találkozom,
amit saját maguk írtak alá.
Aki Internetezik az előbb utóbb úgyis belefut, aki nem tudja lekezelni
úgyis megkérdezi az ismerőstől + oktató ábrák, hogy mire kattintson.

> Aki akarja majd ráteszi https-re, könyvtár feladat.

Így van. Viszont JS-t van hogy letiltják, akár spyware is belebarmol stb.,
a "vakbarát" oldalról már nem is beszélve, hogy JS-t nem kellene
tartalmaznia. JS-t kapcsolgatni meg macerásabb mint egyszer tanusítványt
"telepíteni".

> Javascript az egész lényege: Kliens oldalon jelszóberás-> majd JS MD5 hash
> készítés, eből SHA1 hash készítés, keverek hozzá egy véletlen szerű
> szemetet, és ezt ujra dupla hash, és ezt külöm át a szerverre.
> Szerver ismeri a véletlen szemetet.
> Visszafejthetetlen! Gondod végig, erőebb mint egy alap ssl kapcsolat
> (4szeres hash miatt).
> És ingyen van..

Persze, kikapcsolt JS-nél meg szívás, kösz én JS-ből nem kérnék.
Akkor kezdhetjük elölröl, hogy mitsem ér, ha épp nyilvános könyvtári gépen
keylogger került a gépre. Talán érdemes lenne megnézni, hogy mit is
akarunk ezzel megvédeni:
- Olvasói adatokat? Miért is kellene az alapadotokat kiírni az olvasónak,
úgyis tudja. Változtatni szeretne? Megengedjük neki, hogy Ő írja be,
esetleg tévesen elgépelve (szándékosságtól most tekintsünk el)? Úgy
gondolom semmiképp, ha pl. internet banknál sem tudok alapadatot
módosítani, mert a net azért csak nem biztonságos közeg, talán itt sem
kellene.
Szigorúan nézve beiratkozáskor alapadatokat megadja, könyvtáros ellenörzi
az igazolványokból, majd végül aláírja, mondhatni "szerződik". Többnyire
benne van a szabályzatokba, ha változás van jelentenie kell(ene), amit
ugye már lazábban kezelünk, de hivatalosan újabb papírnak kellene
készülnie. Mert könnyen mondhatná, hogy miért pereljük, mikor levelet sem
kap, adatai nem változtak, ott is lakik, ahogy megadta csak a könyvtáros
vagy más gépelte el. Persze tudom, hogy az élet nem ennyire sarkos....

-Kölcsönzési adatokat? Adott olvasó mit olvas/olvasott? Majdnem senkit nem
érdekel...

- Meghosszabíthatja más könyveit? Talán még meg is köszönik ;-)

- Előjegyzésbe vesz dokumentumokat másnak? Egyrészt az előjegyzések száma
korlátozható. Másrészt nem érzem a súlyát, hogy akkora kárt okozhatna.
Dokumentum beérkezésekor kap értesítőt mire mondja, hogy nem kérte, ekkor
esetleg lehessen letiltani a webes előjegyzst adott felhasználónak és
kész. Az első ilyenkor úgyis jelszót módosít.

A fentiekből majdnem azt is mondhatnám, hogy a http is simán elég
lehet(ne), személyes infókhoz nem jut hozzá, a többit meg anyagi
haszonszerzésre nem tudja felhasználni így potenciálisan nem éri meg
tcpdumpolni.

-- 
  (O__	  ------------------------------------------------------
  //\                       /      Varosi Csokonai Konyvtar
 //  )                     |       Tel.: 59/503-152
 V__/_    szistvan at tux.hu   \      szistvan at mail.vcsk.hu