Action Url Parameter funktioniert nicht wie gewünscht

[bitn2]

Hab hier noch was ähnliches gefunden https://www.3cx.com/community/threads/bug-in-oauth2-url-auth-code-decoding.65876/#post-282000

 

[spuky]

Ich komme dem Fehler noch näher... %CallerNumber% überträgt korrekt +4912345679 macht aber durch urlencode leerzeichen49123456789 daraus!

Ja wobei ein korrektes encoding das plus eher in ein %2B verwandeln sollte... ohne den code zu kennen ist schwer zu sagen was genau warum passiert...

Beim Windows Client ist es das selbe Problem.

Nein das Gegenteil hier macht er kein URL encoding und du musst das + das erhalten bleibt durch %2B ersetzen..

 

[bitn2]

Wenn ich das richtig verstehe ist die Interpretation des + unterschiedlich. Also bei urlencode erzeugt das + ein Leerzeichen (wie in meinem Fall) und bei rawurlencode ein %2b

 

[bitn2]

Nein das Gegenteil hier macht er kein URL encoding und du musst das + das erhalten bleibt durch %2B ersetzen..

Auch beim Windows Client ersetzt er das + durch ein leerzeichen wenn ich es nicht per Batch umwandle in %2b

Das heisst es wird hier urlencode verwendet und nicht die neuere Variante rawurlencode.

 

[bitn2]

Ich denke in diesem Fall ist 3CX am zuge mal auf rawurlencode upzudaten, dann funktioniert das auch so wie gewünscht da das + nicht mehr als Leerzeichen interpretiert wird.

 

[spuky]

Wenn ich das richtig verstehe ist die Interpretation des + unterschiedlich. Also bei urlencode erzeugt das + ein Leerzeichen (wie in meinem Fall) und bei rawurlencode ein %2b

ja wobei das beides PHP Funktionen sind... was die 3CX Devs in Javascript in der Chrome extension machen kann ich nicht sagen... weil die typischen js funktionen:
decodeURIComponent encodeURIComponent decodeURI encodeURI
machen das alle richtig...

Auch beim Windows Client ersetzt er das + durch ein leerzeichen wenn ich es nicht per Batch umwandle in %2b

Da ist es aber der Chrome der das Leerzeichen aus dem Aufrufparameter macht...

 

[bitn2]

Ok, wenn ich das richtig verstehe ist das Problem das Chrome und Edge urlencode machen und nicht rawurlencode?? Wie kann man das denn erzwingen?

Aber erzeugt nicht die 3CX den Link und kopiert ihn in den Browser? Dann wäre das Problem wieder bei 3CX auf rawurlencode umzustellen!?!

Jetzt bin ich völlig verwirrt!

 

[bitn2]

Ok... Also die 3CX kopiert mir den link abcd/+49123456789 in den Browser. Der Browser macht aber aus dem + ein Leerzeichen. Also müsste 3CX den Link eigentlich so übergeben abcd/%2b49123456789.

 

[spuky]

Sorry...für die Verwirrung.. Das öffnen des Chrome Tabs erfolgt durch die Chrome extension... (oder bei windows durch das Aufrufen der URL im Standard Browser)

Windows Client: kein versuch eines encodings... deshalb must du das + in der Batch ersetzten
Chrome extension/3cx Server: missglückter Versuch eines encodings weshalb du eine Leerstelle bekommst.

Und ja das Problem ist bei 3cx nur das die Funktion die die verwenden sollten nicht rawurlencode ist sondern eine entsprechende Javascript, bzw. .net falls das serverseitig passiert, Funktion sein sollte...

Der Browser macht aber aus dem + ein Leerzeichen.

Nein das macht er nicht... zumindest nicht bei der Webextension... weil ein r/+%CallerNumber% ja ein plus und danach ein Leerzeichen bringt..

Also müsste 3CX den Link eigentlich so übergeben abcd/%2b49123456789.

Der Schluss dass die 3cx/Chrome extension das so bringen sollte ist aber richtig...

 

[bitn2]

Dann könnte das ja evtl mal @ilias_3CX oder @JorisR_3CX oder einer der Kollegen weitergeben. Das wäre ja schon fein wenn das funktionieren würde.

 

[bitn2]

Ich hab mich noch mal ein wenig damit beschäftigt. Seitens 3CX muss die Nummer %2b49 und nicht +49 übermittelt werden. Dann funktioniert das wunderbar. Ist das irgendwie umsetzbar?

 

[spuky]

Ich hab mal einen bug report ins englische Forum geworfen...

Solved - BUG: broken URL Encoding CallerNumber Variable in Custom Contact URL

When the %CallerNumber% Variable contains a plus sign (+) the plus sign is converted to a space or missing in the URL Behavior: when defining an url like: case1: http://example.com/search/phone/%CallerNumber% case2: http://example.com/search/phone/%2b%CallerNumber% (trying to fix it) and the...

www.3cx.com

 

[spuky]

nach der Antwort im englischen Forum wenn du:

https://link.firma.com/customer/viewByPhoneNumber/phonenumber/%CallerNumber%

eingibst steht dann in der URL Zeile im Browser

1 https://link.firma.com/customer/viewByPhoneNumber/phonenumber/+49123456789

oder

2 https://link.firma.com/customer/viewByPhoneNumber/phonenumber/49123456789

oder

3 https://link.firma.com/customer/viewByPhoneNumber/phonenumber/ 49123456789

Bei 1 wäre das Verhalten wie bei dem 3cx supporter bei 2 oder 3 wäre es das ich bisher verstanden habe...

 

[spuky]

wenn es sich um den Fall 1 handelt und du irgendwo ein Hosting mit PHP hast könntest du dort folgende Datei ablegen z.B als telefonnummerumschreiben.php

<?php
/***
* Umleiten mit urlencodierter phone number
***/
header("HTTP/1.1 303 See Other");
header("Location: https://link.firma.com/customer/viewByPhoneNumber/phonenumber/".urlencode($_GET['phone']));

dann würdest du z.B in der 3cx eintragen:

https://www.bitnord.de/irgend_ein_ordner/telefonnummerumschreiben.php?phone=%CallerNumber%

und das würde auf https://link.firma.com/customer/viewByPhoneNumber/phonenumber/+49123456789

weiterleiten

Aleternative die Anforerung für das auswerten des + beim Ticketsystem Anbieter einwerfen..

 

[bitn2]

Das ist die Lösung! Das scheint wirklich so zu sein das das Ticketsystem ein %2b erwartet. Mit der PHP Datein klappt das nun. Vielen Dank für die tolle Hilfe. Werde nun trotzdem mal mit dem Hersteller des Ticketsystems in Kontakt treten und gucken ob ich da was erreiche. Ansonsten klappt es ja mit der PHP Datei.

 

[spuky]

Besser ist das... weil wer die logs von dem Webserver hat, hat auch eure Anrufliste... von daher wäre ein interner Webserver mit der Datei besser... auf der anderen Seite habt ihr euch ja schon entschieden die Anrufliste mit dem Ticketsystem Anbieter zu teilen... dann macht der Webhoster den Kohl wahrscheinlich auch nicht mehr fett...

 

[bitn2]

Besser ist das... weil wer die logs von dem Webserver hat, hat auch eure Anrufliste... von daher wäre ein interner Webserver mit der Datei besser... auf der anderen Seite habt ihr euch ja schon entschieden die Anrufliste mit dem Ticketsystem Anbieter zu teilen... dann macht der Webhoster den Kohl wahrscheinlich auch nicht mehr fett...

Das Ticketsystem ist lokal gehostet (können allerdings selber nichts am System ändern) und die Datei kommt bei uns auf den Webspace. Aber trotzdem finde ich das nur eine halb gute Lösung, auch wenns so erstmal funktioniert.

 

[spuky]

Ok wenn das Ticket system lokal ist dann würde ich schauen ob du auch die PHP Datei irgendwo lokal ablegen kannst... z.b. docker container oder falls ne NAS rumsteht wie Synolgy oder Qnap... könnte man es auch da rauf packen... dann bleiben die daten im Haus ;-)

 

[bitn2]

Ok wenn das Ticket system lokal ist dann würde ich schauen ob du auch die PHP Datei irgendwo lokal ablegen kannst... z.b. docker container oder falls ne NAS rumsteht wie Synolgy oder Qnap... könnte man es auch da rauf packen... dann bleiben die daten im Haus ;-)

Wir haben hier im Haus unsere eigenen Server, das bleibt alles intern

 

[spuky]

Dann ist es super... wollte nicht nur eine Lösung bieten ohne auch eine kleine "Datenschutzfolgen abschätzung" zu liefern. Damit andere evtl. das nach der Lösung auch noch lesen.

Freut mich dir geholfen zu haben Gruß in den Norden!