[LØST] Permissions på modules/quickpay/validation.php

[Guest]

Jeg har problemer med kortbetalinger gennem Quickpay efter at Meebox har "optimeret" WEB6.

 

Jeg får ikke nogen callbacks.

 

Hvilken permission har jeres validation.php? Min er 644

 

(Har kontakt til Meebox, men for at være sikker, derfor spørgsmålet)

 

Jeg har problemer med kortbetalinger gennem Quickpay efter at Meebox har "optimeret" WEB6.

 

Jeg får ikke nogen callbacks.

 

Hvilken permission har jeres validation.php? Min er 644

 

(Har kontakt til Meebox, men for at være sikker, derfor spørgsmålet)

Edited April 13, 2013 by Guest (see edit history)

[Prestafan1234]

Mine tilladelser står til det samme.

[presta-dyr]

Det burde være fint med 644. Det kan være, din server har fået ny IP-adresse. Så skal du lige åbne for API-adgang for den nye IP-adresse.

 

/Kjeld

[Guest]

Det viste sig at Meebox havde lagt nogle sikkerheds restriktioner på. Da de pillede dem af igen, virkede det. Men da havde jeg også været nede 15 timer.

De mente forøvrigt at der var fejl i Quickpay callback. Det ville de tale med Quickpay om.

[Guest]

Skal måske lige tilføje, at jeg ligger på WEB6.

Jeg ved ikke om Meebox har lavet samme opdatering på andre servere.

[Guest]

Det viste sig at Meebox havde lagt nogle sikkerheds restriktioner på. Da de pillede dem af igen, virkede det. Men da havde jeg også været nede 15 timer.

De mente forøvrigt at der var fejl i Quickpay callback. Det ville de tale med Quickpay om.

 

Og så kan jeg tilføje, at jeg har spurgt Quickpay. Den henvendelse har de ikke modtaget.

 

Det er lidt bekymrende, at Meebox lægger ekstra sikkerhedsforanstaltninger på, og er nødt til at pille dem af igen.

 

Om det er korrekt at det er et "Quickpay problem" har jeg ingen mening om.

 

Men hvis Quickpay ikke hører om det, og dermed ikke gør noget, og Meebox finder på at lægge den på igen, også på andre servere, så kan det da skabe fatale problemer for adskillige danske webshops.

 

Dét er sgu da bekymrende.

[rtracing]

Og så kan jeg tilføje, at jeg har spurgt Quickpay. Den henvendelse har de ikke modtaget.

 

Det er lidt bekymrende, at Meebox lægger ekstra sikkerhedsforanstaltninger på, og er nødt til at pille dem af igen.

 

Om det er korrekt at det er et "Quickpay problem" har jeg ingen mening om.

 

Men hvis Quickpay ikke hører om det, og dermed ikke gør noget, og Meebox finder på at lægge den på igen, også på andre servere, så kan det da skabe fatale problemer for adskillige danske webshops.

 

Dét er sgu da bekymrende.

 

 

Det har de gjort på andre servere også. De har fjernet den på web14 i dag, der hvor jeg ligger. På min opfordring, efter din udfordring.

 

Hvor lang tid tog det før dit virkede efter det blev fjernet fra serveren?

Edited January 17, 2013 by rtracing (see edit history)

[Guest]

"Hvor lang tid tog det før dit virkede efter det blev fjernet fra serveren?"

 

Det kan jeg ikke svare på. De fjernede det på WEB6 kl. 23.meget sent, og der var ikke ordrer før kl. 07.etellerandet dagen efter.

 

Men formentlig har det virket straks efter at de havde fjernet det.

[Prestafan1234]

Beklager, at jeg lige stjæler denne - men det er i den grad relateret.

 

Jeg sætter en shop op for en kunde på pro15, hvor Quickpay lige pludselig heller ikke virker længere. Men det er ikke samme fejl. Jeg har testet i hele setup forløbet og det gik fint. Når man klikker på betalingskort nu, sker der ingenting. Klikker man igen, får man en grim fejlside om, at der ikke er nogen tilgængelige betalingskort (og det ER der). Jeg er totalt i vildrede, om jeg skal kontakte Quickpay eller Meebox - jeg ved blot, at det virkede med test gennem de sidste par måneder, at setup er det samme som mit eget (som virker) og at det ikke virker nu, hvor shoppen skal gå live i morgen.

 

Jeg har oprettet en ticket hos Meebox - de svarer i det mindste hurtigt - Men jeg aner ikke, om problemet ligger det ene eller det andet sted.

Edited January 17, 2013 by Prestafan1234 (see edit history)

[Guest]

Helt i orden, Ann.

 

Jeg synes, at det er bekymrende at noget virker den ene dag, og ikke virker den anden dag.

 

I mit tilfælde var det Meebox, som pillede ved nogle konfigurationer på en server. Eller flere servere, kan jeg læse mig til i denne tråd.

 

Om det er samme situation i dit tilfælde, ville være rart at vide. Så jeg kunne da godt tænke mig at høre resultatet/løsningen på din situation.

 

Som nævnt var jeg nede i 15 timer. Det skal der måske en uddybning af.

- Betalingen i Quickpay gik igennem.

- Men kunden fik ingen ordrebekræftelse

- Og kurven blev ikke tømt.

 

Det gav mig følgende ekstra arbejde:

- maile til kunderne

- oprette ordrer manuelt med Orlique Order Manager

- Holde styr på ordrer ctr. betalinger i Quickpay og hæve manuelt. Forudsat at kurv og betaling stemte overens.

- Nogle kunder havde slettet kurven, så der lå jeg med en kurv på 0 kr. og en betaling, som jeg ikke kunne hæve.

- Nogle kunder havde forsøgt igen, men med en kurv med et andet indhold. Og så stod jeg med x kurve og x betalinger. Og hvilken en er det så at kunden vil købe. Igen mail til kunden.

 

Jeg vil gætte på, at jeg den mandag havde 3-4 timers ekstra arbejde, som jeg ikke ville have haft, hvis det fungerede.

 

Derudover en række kunder med en dårlig oplevelse med min shop.

 

Det er bare ikke godt nok, Meebox!!!

[presta-dyr]

Jeg har skrevet sammen med Quickpay og Meebox for at prøve at blive klogere på problemet. Jeg har forstået det således:

• Meebox havde installeret mod_security. Det er både godt og fornuftigt, da det kan afværge diverse angreb.
  
• Når man betaler med Quickpay, sker der det, at selve betalingen gennemføres hos Quickpay. Det er på den måde, at kortoplysninger etc. kun ligger hos Quickpay. Når så betalingen er gennemført kalder Quickpay tilbage til webshop med validation.php.
  
• Problemet er, at Quickpay øjensynligt har en forkert MIME-encapsulation, når de kalder validation.php. Dvs. mod_security afviser request'et og svarer med en fejl 500.
  

Så det er ikke "bare" et problem hos Meebox. Jeg håber, Quickpay kan rette måden hvorpå de kalder validation.php, så det også virker med mod_security slået til.

 

/Kjeld

[Guest]

Tak for det Kjeld.

Men betyder det så en ny version af Quickpay?

Hvis JA, så skal vi jo alle have installeret den, inden Meebox kan lave den ændring.

Og jeg sidder altså ikke og installerer nye versioner af Quickpay, hver gang der er en.

Holder ikke engang øje med, om der kommer en.

If it work, don't fix it, you know

[presta-dyr]

Næ, hvis det bare var det. Problemet er, at Quickpays request helt bliver afvist.

 

Det er muligt at slå mod_security fra via .htaccess. Men det er ikke noget, jeg har kunnet afprøve, da jeg ikke selv har set problemet.

 

/Kjeld

[Prestafan1234]

Jeg fik svar fra Meebox om, at de kun har ændret på de billige hoteller (web) og de garanterede, at intet er ændret på pro15 (eller andre pro-hoteller). Jeg har heller ikke problemet på min shop.

 

Problemet med, at man skal klikke to gange på betalingskort, fik jeg ved tests lokaliseret til en fejl i det købte OPC modul - dette er nyere end mit eget. Så det har jeg skrevet til Zelarg (Peter) om i morges - og afventer svar. Når jeg slår standard PrestaShop checkout til kommer man videre til betaling med det samme.

 

Næste problem var, at man fik fejl om, at der ikke var nogen betalingskort. Dette skyldtes, at det var kunden selv, der havde sat Quickpay op, og de havde ikke angivet forretningsnummer - jeg havde kun fået Quickpay Id oplyst til opsætning af modulet. Så da jeg fik adgang til Quickpay og satte forretningsnummer ind, blev denne fejl også løst. Så det virkede selvfølgelig fint under test, da man her kan skrive hvad som helst i ID og komme til betalingsvinduet.

 

Herefter prøvede jeg at gennemføre nogle rigtige køb - og så fik jeg samme fejl, som denne tråd omhandler, for betalingen gennemføres, men kurven bliver ikke tømt, og der er ingen ordrer i BO, men der er betalinger i Quickpay.

 

Så jeg har en shop, hvor problemet kan ses, og det kan testes med .htaccess - og det afprøver jeg gerne.

[presta-dyr]

Prøv dette link for at se, hvordan man disabler mod_security.

 

/Kjeld

[Prestafan1234]

Jeg har tilføjet

 

<IfModule mod_security.c>

SecFilterEngine Off

SecFilterScanPOST Off

</IfModule>

 

i .htaccess filen - øverst før rewrite engine, men det løser desværre ikke problemet. Kurven tømmes ikke, ordren findes ikke i BO, men betalingen går igennem.

[presta-dyr]

Har du også prøvet med dette?

 

   <IfModule mod_security2.c>
   SecRuleEngine Off
   </IfModule>

 

/Kjeld

[Prestafan1234]

Ja, det giver samme resultat

[NickKK]

Presta-dyr; det lyder som præcis samme problematik jeg har med min shop på Netsplads' server, som du prøvede at hjælpe med forleden dag.

 

Fik du nogensinde et brugbart svar fra QuickPay? For noget tyder på, at det er dem, der skal rette :-)

[presta-dyr]

Jeg venter stadig på svar fra Quickpay. Du kan jo prøve at kigge på phpinfo, om mod_security er slået til på din server.

 

/Kjeld

[Guest]

Har lige fjernet [LØST] i titlen, da denne tråd lever endnu.

[DonkMove]

Er denne blevet løst undervejs?

- jeg oplever nemlig præcis det samme.

[presta-dyr]

Hos Meebox?

 

/Kjeld

[Guest]

Hmm. nu udfordrer I mig godt nok på min hukommelse?

 

Jeg har ikke problemet mere, men lige nu kan jeg altså ikke huske hvad løsningen var.

 

Skal nok vende tilbage.

[Guest]

Jeg sætter den til løst igen.

Jeg har formentlig slettet løst, da der kom nogle indlæg omkring Quickpay og andet.

 

Jeg har i mellemtiden installeret Quickpays nyeste modul. Og har ingen problemer mere. Men det havde jeg heller ikke efter Meebox fjernede deres sikkerhedsopdatering.

 

Så hvad der er dit eller dat ved jeg ikke.