19
Nov 07

Wishbuzz – delayed

Vă mulţumesc tuturor celor care v-aţi înscris la wishbuzz newsletter!

S-ar putea, însă, să mă fi grăbit cu explicarea modului de funcţionare... în avântul de entuziasm, am omis unul din principiile de bază în securitatea browserelor: same origin policy.
În alte cuvinte, modelul meu de implementare este imposibil de realizat din punct de vedere tehnic :D .

Săptămâna care-a trecut m-am gândit la alte variante de implementare şi, deşi am găsit câteva soluţii, nici una nu e la fel de comodă ca ideea iniţială.
Aşa că până nu găsesc ceva care să mă satisfacă şi care să permită oricui să folosească aplicaţia în cel mai intuitiv mod posibil, amân implementarea.

Dacă e cineva interesat de tehnicităţi, să mă-ntrebe. :)

Acestea fiind zise, vă doresc o săptămână caldă şi productivă! Mai e un pic până la Crăciun… hang on…

  • Firefox + Greasemonkey :) Ceva gen Shiftspace.
  • RaX
    Iframe-uri, pop-upuri care sa obtina url-uri si content nu prea functioneaza.

    Ca sa vad site-ul lansat, eu as face asa

    1) As incuraja utilizatorii sa traga un link in toolbar-ului browserului (nu e chiar asa chinuitor, ba chiar daca e bine prezentat toata lumea va avea o placere in a face asta)

    javascript:location.href='http://www.wishbuz.ro/cadou.ph...

    Titlul link-ului: WishBuz: Mi-as dori acest produs!

    E logic ce face cadou.php (cred ca ar fi frumos sa se si intoarca catre pagina initiala)

    2) Daca e nevoie permanenta de lista de produse, as incuraja (iarasi) utilizatorii sa deschida un pop-up istet si estetic care sa faca refresh ori de cate ori serverul a primit un produs nou in "cos" (ori un refresh la 5 secunde, nefiind vorba de mare continut, ori un ajax care interogheaza serverul continuu si preia ce e necesar).

    Altfel, daca e necesar un "Vreau acest produs" in pagina shop-ului si alte artificii, un proxy mai bine realizat si cache-uit sanatos poate rezolva problema... (cu mult mai multa munca)
  • Cool, guys! :)
  • eu propun sa ne intalnim maine de la ora 21:00 pe skype/Y!mess si sa tinem o conferinta pe tema asta :) iar log-ul il postam pentru cei care nu au participat. De ce maine? Ca sa putem testa idei si sa le aducem, gata testate.
  • Tristan
    In esenta nu e nimic mai mult decat ce face serviciul de traducere "on the fly" de la google numai ca ai o sarcina mult mai usoara, sa inlocuiesti cateva href-uri/src-uri.
  • Tristan
    De a cui CPU vorbesti? a userului sau a serverului?

    1) A serverului - nu e nici o presiune, in esenta sunt doar cateva regexp-uri pentru a inlocui src-urile la imagini/scripturi/css-uri

    2.a) se poate opta la inlocuirea linkurilor tot direct din proxy, ar fi doar un regexp in plus, nu e mare chin pentru procesor (din experienta)
    2.b) se pot inlocui linkurile si din JS in partea de browser, aici nu pot sa zic din experienta dar nu cred inlocuirea fie si la 100 de linkuri din pagina cu o librarie care are selectori scrisi ca lumea (DOMQuery/Jquery) ar dura mai mult de 1s (defapt cred ca ar fi ceva de genu 0.1).

    Ramane de vazut totusi ce e mai bine 2a sau 2b.

    Cat despre traba cu div/iframe, iframe e mai bine. Daca tot avem sursa paginii in proxy, ce ne opreste sa daugam la sfarsit un propriu care atribuie la o variabila globala url-ul paginii pe care se afla acum. adica proxyul stie ce pagina a cerut acum deci poate face ceva de genu myvar = {URL}

    Si paote tu nu puteai citi/interactiona cu src-ul la iframe tocmai din cauza la SOP.
    Si acum pe final ce scriu .. it hit me. acum daca ai access la dom-ul din iframe:
    document.getElementBy('myiframe').location

    asta nu ar merge? eu cred ca asta se modifica pe masura ce useru navigheaza.
  • OK, hai sa vedem cum ar functiona:

    Nu putem interactiona cu iframe-ul ("src" ramane neschimbat la valoarea initiala). Deci nu facem iframe, ci incarcam totul intr-un div, corect?
    Asta presupune un request al primei pagini de e-shop. Buuun. O afisam, cu linkurile inlocuite etc.
    User.click() pe un link. Proxy isi face treaba si afiseaza pagina respectiva.
    ...
    Userul ajunge la pagina unui produs, iar acolo ii dam posibilitatea sa adauge produsul respectiv in wishlist.

    Well, cred ca ar functiona, dar iti dai seama ce presiune pe CPU?

    La asa ceva te gandesti?
  • Tristan
    De ce copie locala, de unde ai luat asta?
    Eu vorbesc de un script proxy care face request de fiecare data la pagina de magazin care se doreste a fi afisata in iframe.
  • Tristan,
    solutia asta presupune sa am o copie locala si sincronizata a magazinului virtual. Copy/paste.
    Ti se pare o solutie eficienta? :)
  • Tristan
    Da, simplist spus exact asta face ( evident nu cu functia de care ai zis tu, un proxy ca lumea nu e doar get_file_contents )
    Dar daca ar face numai asta, nu cred ca situ ar arata asa cum arata in linkurile care le-am postat (toti folosesc linkuri relative)
    daca erai un pic atent vedeai ca pana si majoritatea javascripturilor din site ( ex meniul dinamic de la amazon ), nu e mare chestie, e un regexp pentru modificarea linkurilor relative.
    Nu am zis ca am inventat ceva nou, da e ceva care merge si vrei nu vrei, tot la un proxy vei ajunge.

    Disconsiderarea unei solutii doar pentru ca ti se pare simpla .... :)
    Sa vedem argumente contra acestei soluti ...

    Acest mod de abordare iti rezolva problema de SOP, ai acces complet la dom-ul din iframe, utilizatorului in 90% din cazuri in iframe situl pe care se navigheaza apare aproape identic.

    seba: da, aia e ideea si inlocuirea linkurilor ... sa o faca browseru cu javascriptu ca procesoru de server e scump.

    >hey man,
    >ce anume face scriptul, get_file_contents($url) si afiseaza? :D
  • Site-urile pot sa includa cum includ analytics si un js pentru wishbuzz... doar sa nu le incetineasca timpii de incarcare.
    Restul e negociere.
  • Scuze, seba, commentul respectiv intrase in moderare si am uitat sa-l activez :D.
  • seba
    sorry,
    nu am citit commnet-ul de mai sus, nu stiu de ce, ori nu mi-a aparut prima data, ori m-a luat valul :-)
  • seba
    si mai simplu este sa grabbui tu site-ul, il parsezi, inlocuiesti toate url-urile cu ceva de genul:
    http://wishbuzz.ro?parse=http:..., faci inlocuirile in DOM unde ai nevoie si abia apoi afisezi toata treaba in iframe, propriu-zis overhead-ul este doar la inlocuirea link-urilor. Nu e simplu, trebuie facut server-size, si minusul imens apare cand un site isi va schimba design-ul :). Daca vrei putem continua discutia pe mail.
  • Am testat mai devreme ideea ta, seba, dar src-ul unui iframe ramane neschimbat si nu tine cont de navigarea din interior.
  • seba
    Nu e asa de greu de modificat ideea de baza :).
    Utilizatorul navigheaza pana la pagina produsului si de acolo ii iei tu linkul iframe-ului in momentul respectiv. Butonul de adauga produs se afla in interfata ta, nu trebuie sa modifici contentul site-ului vizitat. M-am lovit si eu de o problema asemanatoare la un moment dat :).

    Cu timpul iti faci siteuri partenere si se schimba situatia :).
  • Dai o bere pentru solutie? :)

    POC:
    http://www.lightdesignworks.co...
    http://www.lightdesignworks.co...

    evident, scriptu nu e perfect, se pot face o tona de inbunatatiri dar baza este, si e posibil de facut ce vrei tu.

    F@#$ same origin policy ;)

    PS: scriptul il voi sterge de pe server in cateva zile, din motive evidente :)
  • nimeni
    Ntz, ntz. Deci n-ai citit commentul meu :)
blog comments powered by Disqus