választoi mozgalom név ellenörzés

[utopszkij]

Ez a funkció nincs megoldva azzal hogy az asurel belép a joomla adminba!
Példa:

1. Hecker Hugo regisztrál az ADA -ba "nick1" nevet használva, email aktiválással, a választoi mozgalomba megadja a "Hecker Hugo" valódi nevét, de egy hamis személyi számot használ..
2. Ugyanő ujra regel az ADA -ba "nick2" nevet és másik email cimt használva, a választoi mozgalom oldalán "Gyurcsány Ferenc" nevet ad meg., valódi személyi számát használja.
3. elmegy az assurelhez ott "nick2" vel logol be, az assurel látja a személyi igazolványát, és a vm admin oldalon azt hogy van egy még nem assurált "Hacker Hugó" user - megadja a "magyar" és a "vm" assurálást. Ezután a user a "nick2" belépéssel a választói mozgalom oldalaán Gyurcsány Ferenc" névvel tud ténykedni.

[Claymanus]

Pár megjegyzés a fentiekhez.

• ADA nem tárol nick nevet.
• ez nem bug, hanem rendszer szintű issue
• Teljesen igazad van abban, hogy a kulcs nélküli (a személy neve nem kulcs) data join -ra alapozni egy assurance kiadását meglehetősen komolytalan.

Egy kicsit absztracháljuk el a témát:

1. app típusu assurance felteteleit az app(szervezete) határozza meg. Ebben lehet olyan előírás, hogy valamilyen adatot -amit az app nyilvántart, de az ada nem- ellenőrizni kell. Tehát az adat csak az app rendszerében áll rendelkezésre.
2. Ennek az adatnak az ellenőrzése akkor lehet hiteles, ha a két rendszerben tárolt user rekord egyszerre ellenőrizhető úgy hogy biztosítva van, hogy az assurer számára megjelenő két rekord ugyanahhoz a userhez tartozik.
3. A két rendszerben (ada és app) tárolt user rekord között az app specifikus userID a kulcs.
4. A 2 pontban definiált feltételekkel magvalósítandó assuráláshoz ezért implementálnunk kell egy olyan funkcioalitást, ami az assurálás folyamán a tanusító felületen képes megjeleníteni az app által ellenőrizni kívánt információt.
5. Ehhez szükség va app oldalról egy olyan interface-re, ahova az ada Assurance kiadó UI be tud hívni. Ez az interface a proxy ID-t és az ellenőrizendő adatot várja, a válasza pedig OK, vagy N.OK.
6. Az assurer oldalon be kell írjuk az ellenőrizendő adatot, ha automatán akarjuk ellenőrizni. Ezután ezt
   a) vagy eküldjük az adának, hogy aztán az ada server kérdezzen rá az app-nál a user adat valódiságára
   b) vagy a kliens (azaz assurer UI) közvetlenül kérdezi le az appot, és az eredmény függvényében kezeményezi az assurance kiadását.
   mindkét processznek vannak előnyei és hátrányai, amit meg kellene rágnunk. Mondjuk a b) csak app oldali fejlesztést kíván, meg némi beavatkozást az ADA frontenden ezt támogatandó. a) -hoz viszont nem kell, hogy az assurer bejelentkezve legyen az app-ba assurálás közben, viszont ada beckend oldalon is egy nagy rakás fejlesztést kell eszközölni.
7. Alapvetés: Az assurer sem feltétlenül megbízható, a user meg még anyira sem. Erre kell készüljünk.

Tekintettel arra, hogy az app specifikus assurálás, az ada wish list-ben már a kezdetek óta benne van, itt az ídő ennek a támogatását is implementálni.

[krosza]

Tibor, ha jól értem az a problémád, hogy regisztrációkor a user megadhat más email-t mint, amit az adán használt, és az adán használt email-t pedig a te rendszered nem ismeri. Viszont a usernek ismernie kell, egyébként a tanúsító semmilyen igazolást nem tud neki adni. Elvben előfordulhat, hogy a vm email alapján lekért user név egyezése ok, de ez nem jelenti feltétlen azt, hogy ez a user kap "vm" igazolást, az csak az ada-s email alapján lekért user fogja meg kapni. Ilyenkor a vm -es email usernél nem lesz vm igazolás. és Ez a tanúsítás után kiderül, persze frissítés stb problémák miatt ez lehet csak később látszik. A problémádat egyelőre az megoldja, ha kötelezővé tesszük, a vm rendszerében az ada email használatát (kvázi azonosítóként), tehát regisztrációkor az ada email kell beírnia (odaírjuk különben nem kap "vm" igazolást ehhez a reghez). Ettől függetlenül megadhat levelezési második email-t. Abban teljesen igazad van hogy ez eléggé macerás a user számára, ezért itt én két irányba mennék tovább, ha az előbbit elvetjük: - vm reg =csak egy nick megadása a kötelező. (a vm rendszerben csak nick alapján lehet keresni eset) A Tanúsító láthatja a vmben regisztrált ADA app specifikus id-t. Az ADA tanúsítói felületen ezt az ID-t meg lehet mutatni , ezután (szemre egyelőre) össze tudja hasonlítani a kettőt, ha ok akkor van csak tanúsítás, miután ez egyelőre nem túl gyakori eset talán elmegy vagy - oldjuk meg hogy a vm reg alatt az ada felületre beírt email címet a vm automatikusan megkapja és tárolja (persze a user egyetértésével), ez persze azADA- FB regeknél nem működik, és akkor sem, ha a user az ADA-ban épp be van jelentkezve az ADA-ba és úgy regisztrál szk 2017-01-04 12:06 GMT+01:00 György Peng <[email protected]>:

…

Pár megjegyzés a fentiekhez. - ADA nem tárol nick nevet. - ez nem bug, hanem rendszer szintű issue - Teljesen igazad van abban, hogy a kulcs nélküli (a személy neve nem kulcs) data join -ra alapozni egy assurance kiadását meglehetősen komolytalan. Egy kicsit absztracháljuk el a témát: 1. app típusu assurance felteteleit az app(szervezete) határozza meg. Ebben lehet olyan előírás, hogy valamilyen adatot -amit az app nyilvántart, de az ada nem- ellenőrizni kell. Tehát az adat csak az app rendszerében áll rendelkezésre. 2. Ennek az adatnak az ellenőrzése akkor lehet hiteles, ha a két rendszerben tárolt user rekord egyszerre ellenőrizhető úgy hogy biztosítva van, hogy az assurer számára megjelenő két rekord ugyanahhoz a userhez tartozik. 3. A két rendszerben (ada és app) tárolt user rekord között az app specifikus userID a kulcs. 4. A 2 pontban definiált feltételekkel magvalósítandó assuráláshoz ezért implementálnunk kell egy olyan funkcioalitást, ami az assurálás folyamán a tanusító felületen képes megjeleníteni az app által ellenőrizni kívánt információt. 5. Ehhez szükség va app oldalról egy olyan interface-re, ahova az ada Assurance kiadó UI be tud hívni. Ez az interface a proxy ID-t és az ellenőrizendő adatot várja, a válasza pedig OK, vagy N.OK. 6. Az assurer oldalon be kell írjuk az ellenőrizendő adatot, ha automatán akarjuk ellenőrizni. Ezután ezt a) vagy eküldjük az adának, hogy aztán az ada server kérdezzen rá az app-nál a user adat valódiságára b) vagy a kliens (azaz assurer UI) közvetlenül kérdezi le az appot, és az eredmény függvényében kezeményezi az assurance kiadását. mindkét processznek vannak előnyei és hátrányai, amit meg kellene rágnunk. Mondjuk a b) csak app oldali fejlesztést kíván, meg némi beavatkozást az ADA frontenden ezt támogatandó. a) -hoz viszont nem kell, hogy az assurer bejelentkezve legyen az app-ba assurálás közben, viszont ada beckend oldalon is egy nagy rakás fejlesztést kell eszközölni Tekintettel arra, hogy az app specifikus assurálás, az ada wish list-ben már a kezdetek óta benne van, itt az ídő ennek a támogatását is implementálni. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMNFgh6ec8iIA4n5BHh0VuuxtPx3O3kjks5rO30bgaJpZM4LZ9aJ> .

[krosza]

Gyuri, az nem oldaná meg a problémát, ha az app specifikus id- t a tanúsítói felületre csak be kell másolni a tanúsítónak, ha app igazolást adunk ki, és ezt ellenőrzi az ADA UI? 2017-01-04 12:06 GMT+01:00 György Peng <[email protected]>:

…

Pár megjegyzés a fentiekhez. - ADA nem tárol nick nevet. - ez nem bug, hanem rendszer szintű issue - Teljesen igazad van abban, hogy a kulcs nélküli (a személy neve nem kulcs) data join -ra alapozni egy assurance kiadását meglehetősen komolytalan. Egy kicsit absztracháljuk el a témát: 1. app típusu assurance felteteleit az app(szervezete) határozza meg. Ebben lehet olyan előírás, hogy valamilyen adatot -amit az app nyilvántart, de az ada nem- ellenőrizni kell. Tehát az adat csak az app rendszerében áll rendelkezésre. 2. Ennek az adatnak az ellenőrzése akkor lehet hiteles, ha a két rendszerben tárolt user rekord egyszerre ellenőrizhető úgy hogy biztosítva van, hogy az assurer számára megjelenő két rekord ugyanahhoz a userhez tartozik. 3. A két rendszerben (ada és app) tárolt user rekord között az app specifikus userID a kulcs. 4. A 2 pontban definiált feltételekkel magvalósítandó assuráláshoz ezért implementálnunk kell egy olyan funkcioalitást, ami az assurálás folyamán a tanusító felületen képes megjeleníteni az app által ellenőrizni kívánt információt. 5. Ehhez szükség va app oldalról egy olyan interface-re, ahova az ada Assurance kiadó UI be tud hívni. Ez az interface a proxy ID-t és az ellenőrizendő adatot várja, a válasza pedig OK, vagy N.OK. 6. Az assurer oldalon be kell írjuk az ellenőrizendő adatot, ha automatán akarjuk ellenőrizni. Ezután ezt a) vagy eküldjük az adának, hogy aztán az ada server kérdezzen rá az app-nál a user adat valódiságára b) vagy a kliens (azaz assurer UI) közvetlenül kérdezi le az appot, és az eredmény függvényében kezeményezi az assurance kiadását. mindkét processznek vannak előnyei és hátrányai, amit meg kellene rágnunk. Mondjuk a b) csak app oldali fejlesztést kíván, meg némi beavatkozást az ADA frontenden ezt támogatandó. a) -hoz viszont nem kell, hogy az assurer bejelentkezve legyen az app-ba assurálás közben, viszont ada beckend oldalon is egy nagy rakás fejlesztést kell eszközölni Tekintettel arra, hogy az app specifikus assurálás, az ada wish list-ben már a kezdetek óta benne van, itt az ídő ennek a támogatását is implementálni. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMNFgh6ec8iIA4n5BHh0VuuxtPx3O3kjks5rO30bgaJpZM4LZ9aJ> .

[Claymanus]

A Tibornak szóló reflektációdra reagálnék először.

1. Félreérted a problémát. Nem email címekről szól a dolog, hanem arról, hogy nem lehet biztonsággal összekötni a két rendszerben a felhasználót, ha azt a tegnapi megbeszélésen rögzített folyamat alapján történik. Tibor ehhez írt le egy példát, amiben egy fake assurance kiadásának lehetőségét írja le.

A nekem címzett kérdésedhez:

1. A user app specifikus ID-jéhez az assurernek semmi köze, mint ahogy az email címéhez sem. Az assurer feladata, hogy leellenőrizze azokat az adatokat amiket le kell ellenőrizni. Az app id nem ilyen adat.
2. Pontosítok az ellenőrzést a rendszernek kell elvégeznie (mint ahogy a magyar igazolás kiadásánál is), az assurernak csak az a feladata, hogy az input formok a valóságnak megfelelő kitöltését hitelesítse.

Visszakérdezek: mi az akadálya annak, hogy az adába implementáljuk végre az app specifikus assurance kiadás támogatását? Mi indokolja azt, hogy az eddigi alapvetéseink megerőszakolásával mindenféle humán akciót megkövetelő processzekre kényszerítsük a usert meg az assurert?

[krosza]

1. ezt értettem eddig is, csak az a preferenciám, hogy csak akkor fejlesszünk, ha az feltétlen szükséges és ha ezt az esetszám is indokolja a Tibor példája elég specifikus, erre írtam a fejlesztés nélküli megoldásokat ----- 1.. " a tanúsítónak nincs köze" az email címhez eléggé van mert anélkül nem tud tanúsítani .... az app id nem tartom problémának biztonsági szempontból, mert épp ezért csináltuk különbözőnek az ada id-től, de ez nyilván nézőpont kérdése 2. Ezzel egyetértek nyilván... de ld első pontot végül, én úgy értettem, hogy a vm mindenképpen akar email-t ezért ez nem felesleges, az lehet szempont, hogy ezt nem akarja hogy azonos legyen az adas email-el, de ez a user szám vleg elég alacsony....és egyébként úgy érzem nagyon app specifikus a fejlesztés, *de nem ellenzem,* hanem próbálok a meglévő eszközökkel dolgozni 2017-01-04 13:53 GMT+01:00 György Peng <[email protected]>:

…

A Tibornak szóló reflektációdra reagálnék először. 1. Félreérted a problémát. Nem email címekről szól a dolog, hanem arról, hogy nem lehet biztonsággal összekötni a két rendszerben a felhasználót, ha azt a tegnapi megbeszélésen rögzített folyamat alapján történik. Tibor ehhez írt le egy példát, amiben egy fake assurance kiadásának lehetőségét írja le. A nekem címzett kérdésedhez: 1. A user app specifikus ID-jéhez az assurernek semmi köze, mint ahogy az email címéhez sem. Az assurer feladata, hogy leellenőrizze azokat az adatokat amiket le kell ellenőrizni. Az app id nem ilyen adat. 2. Pontosítok az ellenőrzést a rendszernek kell elvégeznie (mint ahogy a magyar igazolás kiadásánál is), az assurernak csak az a feladata, hogy az input formok a valóságnak megfelelő kitöltését hitelesítse. Visszakérdezek: mi az akadálya annak, hogy az adába implementáljuk végre az app specifikus assurance kiadás támogatását? Mi indokolja azt, hogy az eddigi alapvetéseink megerőszakolásával mindenféle humán akciót megkövetelő processzekre kényszerítsük a usert meg az assurert? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMNFgow60-FosTe9YlRIyucN48MNXFK8ks5rO5ZZgaJpZM4LZ9aJ> .

[Claymanus]

1. akkor fejlesszünk, ha szükséges.

• ez az app specifikus igazolás az ada egyik legmenőbb fícsöre lenne, amivel eddig is kecsegtettük az appokat. Ez az a fícsör ami érdekessé tenné az app számára az ada autentikációt. Most van rá igény, most kell megcsinálni.
• tegnap számoltuk ki, hogy worst case hány user, illetve assurer lehet. Csak nem kellene már szopatni őket ezzekkel a kézihajtányos ötletekkel, amikor egy max 10napos fejlesztésről beszélünk első körben.

---

1.. Az emil alapján történő adatlekérdezés csak átmeneti lehetőség, amíg a tanusítőválasztás folyamata nem lesz automatikus, Akkor már lesz a tanusítónak egy listája a tanusító felületén, hogy kiket kell tanusítania, és minden userhez lesz egy gomb, amivel lekérdezheti a releváns adatokat. bájdövéj addig el sem tudná kezdeni az tanusítást, amíg a szükséges feltételek nem adottak (emailcheck, hashgiven), szóval a tanusítónak nem feltétlenül kell megismernie a user email címét.

3. a vm kap adától proxy emil címet, ezt a user átírhatja, ha akarja, de ha az assurance kiadásának feltétele, akkor nyilván ezt is ellenőrizni kell tudni valahogy, ami további problémákat vet fel. Az ada által adott proxy email címet nyilván nem kell ellenőrizni.

[Claymanus]

edemo/PDOauth#832

[utopszkij]

Egy eretnek gondolat:

1. Feltehetőleg sok olyan ember lesz aki "csak" az előválasztás miatt keresi fel az assurelt.
2. Ha már lesz az assurálási rendszerben egy callbackurl -es hivás az előválasztás sw fel a névellenrözéshez, akkor az egyúttal az OEVK jelölt választó szavazó formot is megjelenithetné, az asuuser - amennyiben a user ezt kéri - azonnal le is adhatná a user szavazatát. Ezzel a módszerrel a NET -et nem használó, attól idegenkedő emberek is részt tudnak venni az előválasztáson., az ő számukra ez kvázi egy személyes megjelenéssel megvalosuló szavazás lenne. "Mellék termékként" ADA regje keletkezik, mit később esetleg használhat másra is.