[feature] email_gfx beschikbaar voor niet ingelogde user

[elevator]

Ik (en bv. Zwerver in de APL Policy Ook) gebruiken de email_gfx in de FAQ's om de mail addressen van de moderators te tonen - nu zijn die niet beschikbaar als een user ingelogd is wat dus betekent dat niet ingelogde users ons niet kunnen mailen.

Is er een optie dit vrij te geven voor niet ingelogde users?

[Osiris]

Ehm, naar mijn weten is het profiel niet zichtbaar voor niet-ingelogde gebruikers, *juist* om die e-mail-adressen (onder andere)..

Kost het zoveel moeite om zelf ff een plaatje te maken?

[moto-moi]

Als je zo plaatjes kunt rippen uit de myreact, of je moet zo'n plaatje zelf maken en uploaden, wat lijkt je zelf het handigste ? Juist.

[Spider.007]

Tjah.. opzich heeft moto natuurlijk wel een punt; vooral omdat de emailadressen van moderators nooit zullen veranderen. Desnoods maak je zelf een PHP die dit soort grafix genereert; maar dit soort statische informatie kan je volgens mijn ook zelf erg eenvoudig genereren Zolang moderators niet te vaak van naam wisselen levert dat geen enkel probleem op

[elevator]

In de WOS FAQ staan ook de MSN addressen van de moderators (ok.. alleen de mijne, maar het gaat om het idee ) en ik heb geleerd dat je informatie zo weinig mogelijk dubbel moet opslaan

[Osiris]

Ik heb toch liever dat jij een PNG-tje ff dubbel maakt ipv dat mensen lekker alle "http://gathering.tweakers.net/forum/user_email_gfx/".$id gaan lopen leechen.. Immers, voor 't plaatje heb je echt geen profiel nodig.. 't Plaatje zelf is al genoeg om te OCR-en

[elevator]

Als je nou een bot schrijft die alle profielen van GoT gaat jatten - denk je dan niet dat ze net zo snel nog even een ReactID cookie mee kunnen sturen en het als nog kunnen?

[Osiris]

Uiteraard, maar die functie zit er niet voor niets, toch?

[elevator]

Dat is dus maar heel erg de vraag - beperkingen baseren op een soort van scheinveiiigheid zijn niet altijd even nuttig imho

[Osiris]

Een hogere drempel wil natuurlijk niet meteen impliceren dat het ook een scheinveiligheid is. Pas zodra je geloofd dat die methode dé ultieme methode is waardoor je de "bad guys" tegenhoud, is het een scheinveiligheid. IMO is het nu een extra drempel die men moet overbruggen.

_{Plus, zo moeilijk is "Save as" en ff uppen naar je crewspace toch niet?}

[We Are Borg]

Osiris schreef op 26 september 2004 @ 14:05:
_{Plus, zo moeilijk is "Save as" en ff uppen naar je crewspace toch niet?}

Een save as veranderd niet mee wanneer iemand het e-mail adres aanpast . Maar goed, dat gebeurd bijna nooit bij crew members denk ik zo dus je hebt wel een punt.

[Janoz]

elevator schreef op 26 september 2004 @ 14:01:
Dat is dus maar heel erg de vraag - beperkingen baseren op een soort van scheinveiiigheid zijn niet altijd even nuttig imho

Mwah... een plaatje dat vrij beschikbaar is met als enige beveiliging dat deze normalitair alleen op een beveiligde pagina wordt vertoond.

vs

Een plaatje waarbij exact dezelfde toegangs voorwaarden worden gecontroleerd als de pagina waarop deze normalitair alleen beschikbaar is.

Welke van beiden is de schijnveiligheid?

[elevator]

Osiris schreef op 26 september 2004 @ 14:05:
Een hogere drempel wil natuurlijk niet meteen impliceren dat het ook een scheinveiligheid is.

Het mee sturen van een cookie is geen daadwerkelijke drempel als je het object bekijkt - het is een extra stap die je moet nemen, maar een stap die erg simpel te nemen is

_{Plus, zo moeilijk is "Save as" en ff uppen naar je crewspace toch niet?}

Ik zie hier verder de relevantie overigens niet meer van in - ik vraag een feature aan en geef daar een motivatie bij, uiteraard weet ik dat er altnernatieven mogelijk zijn

Nu lijkt het mij verder aan chem om aan te geven ofdat dit haal baar is

[elevator]

Janoz schreef op 26 september 2004 @ 14:29:
Mwah... een plaatje dat vrij beschikbaar is met als enige beveiliging dat deze normalitair alleen op een beveiligde pagina wordt vertoond.

Ik suggereer dan ook niet dat het een beveiliging is? Ik geef enkel aan dat de huidige beveiliging niet afdoende gaat zijn tegen hetgene waar het tegen moet beveiligen, en dat het dan dus zinloos is om nog een beveiliging te handhaven

[Spider.007]

op een kleiner forum waar aanmeldingen handmatig worden goedgekeurt heeft het niet beschikbaar zijn van deze images wel nut. Wellicht is het een idee als Parse een optie inbouwt waarmee deze plaatjes ook voor niet ingelogde users zichtbaar worden gemaakt zodat dit op GoT eventueel aangezet kan worden?

[ACM]

elevator schreef op 26 september 2004 @ 14:34:
Ik suggereer dan ook niet dat het een beveiliging is? Ik geef enkel aan dat de huidige beveiliging niet afdoende gaat zijn tegen hetgene waar het tegen moet beveiligen, en dat het dan dus zinloos is om nog een beveiliging te handhaven

In die lijn valt ook het argument om de sloten maar van je deur te halen, de auto niet op slot te parkeren etc... Want het is toch te omzeilen.

De beveiliging met een ingelogde-sessie is zeker niet afdoende om te garanderen dat de email-plaatjes niet geript worden. Het is wel weer een stap extra om te slechten voor een kwaadwillende. En elke stap extra zorgt ervoor dat kwaadwillenden zich (kunnen) gaan afvragen of het de moeite nog wel waard is.

Bovendien is de stap niet toegevoegd omdat het een leuke feature is... De stap is toegevoegd omdat er serieuze redenen waren om die erbij te plaatsen. Er is in het verleden al enkele malen moeite gedaan om alle e-mailadressen/profielen op GoT te verzamelen en dat wensen we zo veel mogelijk tegen te gaan.

[ Voor 17% gewijzigd door ACM op 26-09-2004 15:19 ]

[elevator]

ACM schreef op 26 september 2004 @ 15:17:
In die lijn valt ook het argument om de sloten maar van je deur te halen, de auto niet op slot te parkeren etc... Want het is toch te omzeilen.

Niet helemaal aangezien een slot van de deur wel degelijke vertraagt / moeite kost

Als je echter een bot schrijft om mail addressen automatisch te downloaden van GoT - dan is het pakweg 1 regel extra om een ReactID mee sturen.

Als je het dan wilt vergelijken zou ik het dus eerder met een half hoog ijzeren tuinhekje doen dan met iets anders

[ACM]

Je zult anders ook voor een geldig ReactID van een ingelogde sessie moeten zorgen. Dat betekent dus dat je een groot risico neemt met je eigen account, of dat je een nieuw account moet aanmaken.

Twee deelstappen die je voor het gemak even overslaat.

[Osiris]

Plus dat mocht er iets in de AV over rippen van e-mails staan, je die AV ook overtreedt doordat je daarmee akkoord gaat en heeft Tweakers.net eventueel ook een poot op te staan qua judirische meuk..

[chem]

In React 1.whatever gaan we configurabel maken welke acties er zonder ingelogd te zijn uitgevoerd kunnen worden.
Dan mogen jullie dit uitvechten