URL umleiten (URL-Redirect) mit Freetz: bitte um Anleitung

er13 · 13 Jun 2019

Ehrlich gesagt weiß ich nicht, worüber Du Dich freust bzw. was Du testen möchtest. Ich habe geschrieben und hoffentlich begründet, dass es für https nicht geht (zumindest, wenn als Werkzeug nur privoxy zur Verfügung steht).

Edit: es sei denn, Du hast den Admin-seitigen Zugriff auf lima-city und kannst einen virtuellen Web-Server für openapi.klicktel.de einrichten/konfigurieren.

LeeB · 14 Jun 2019

Hatte gestern sehr wenig Zeit und mich über den zusätzlichen Filter, dass openapi.klicktel.de direkt nach /mahalo.lima-city.de umgeleitet & dort auf / gesucht wird, und über deine rewrites generell gefreut, konnte mich aber jetzt erst mit deiner Begründung beschäftigen.

~~Zwei~~ Eine Fragen habe ich noch bevor ich diesen Weg aufgebe:
1. Ich möchte an dieser Stelle die Angaben anderer Gigaset-Benutzer selbst überprüfen und mir die *genaue* URL anschauen, die das online-fonbuch meines Gigasets hier konkret abfragt. Wirklich nur openapi.klicktel.de ohne weiteren substring? Und so wie für's CH-fonbuch wirklich https? Der proivoxy Log ist sehr dürftig und liefert diese Info nicht. Gibt es in oder für Freetz (oder wenn nicht dann für's FritzOS) einen genaueren Log oder soetwas wie einen network traffic monitor, der alles auflistet was raus geht? vnstat ist auf packages – Freetz ja ausgegraut
(Ich hatte so etwas vor etlichen Jahren mal in eine alte FB installiert, aber kann keine Aufzeichnungen mehr finden).

2. Auf einem anderen shared Server jedoch mit eigener Domain <meine.domain> und *nur* http (kein https) kann ich auf / natürlich einen Ordner openapi.klicktel.de anlegen. Wie sähe denn der rewrite dafür aus, also quasi einen "http tunnel" (falls es sowas gibt) für einen "cloaked/ masked" redirect (kennen den genauen Ausdruck nicht), so dass http://openapi.klicktel.de -> meine.domain/openapi.klicktel.de darstellt (so wie jetzt https://open..) ? Ich habe schon versucht deinen Filter umzuschreiben, leider erfolglos.

Mit mehr als dieser letzten Frage möchte ich dich dann auch nicht mehr bemühen, er13.

LeeB · 16 Jun 2019

@eisbaerin das war natürlich das erste was ich gemacht habe.. nur leider funktioniert das hier nicht wie auf Fritzbox: Online-Traffic aufzeichen - so geht's - PC Magazin beschrieben (ganz unten auf Inhalt dann FRITZ!Box Support:

Die angegebene URL wurde nicht gefunden. Sie werden auf die Startseite der FRITZ!Box weitergeleitet.

Die Dinge sind manchmal offensichtlich nicht so konsistent wie sie sein sollten. Spare dir gerne für die Zukunft deine Arroganz, OK? Schadet nur deinem Ansehen. Wenn du nicht hilfreich sein willst dann schreib lieber gar nichts..

Ich hatte bislang keine Zeit gehabt mich damit weiter zu beschäftigen. Dann viel mir aber ein dass das Support- Paket ja aus Platzgründen für Freetz entfernt wurde. Ich hab dann vorhin trotzdem mal den direkten Link zum Paketmonitor fritz.box/html/capture.html probiert, und der funktioniert auch ohne Support-Paket! Heut abend werde ich mir mal mit Wireshark den Log anschauen.

LeeB · 16 Jun 2019

Wireshark: beim Aufruf vom klicktel-fonbuch auf dem Gigaset:
Source Port: 60291
Destination Port: 80
also (im Gegensatz zum fonbuch-Aufruf f.d. Schweiz https://tel.search.ch) http ...

er13 · 16 Jun 2019

Und wie lautet der http-Link, der aufgerufen wird?

Ansonsten (als Hinweis) geht das Debuggen durchaus auch mit privoxy:

Code:

# Debug-Level setzen (s. https://www.privoxy.org/user-manual/config.html#DEBUGGING)
modconf set privoxy PRIVOXY_LOGLEVEL=$((1+1024 +8 +64+128))
# und speichern
modconf save privoxy
modsave flash

# privoxy.log leeren
echo -n "" > /var/log/privoxy.log

# privoxy restarten
/etc/init.d/rc.privoxy restart

Das Log steht dann unter "Status/privoxy" im Freetz-WebIf zur Verfügung oder direkt unter /var/log/privoxy.log

LeeB · 16 Jun 2019

er13 schrieb:
Und wie lautet der http-Link, der aufgerufen wird?

Den habe ich via Wireshark leider nicht finden können.

Ansonsten (als Hinweis) geht das Debuggen durchaus auch mit privoxy:

Das Log steht dann unter "Status/privoxy" im Freetz-WebIf zur Verfügung oder direkt unter /var/log/privoxy.log

OK prima - ich werd mal schauen ob ich so etwas mehr auslesen kann.

LeeB · 17 Jun 2019

Wireshark gibt als Ziel immer nur 145.253.193.190 aus = die IP via ping openapi.klicktel.de, obwohl im Gigaset der Proxy aktiv ist (IP 192.168.178.1 + Port 8118).

In Privoxy sind beide redirects activ und funktionieren im Browser auf http:

Code:

+redirect{s@://openapi\.klicktel\.de/@://meine.domain/openapi/@}}
openapi.klicktel.de

{+redirect{s@://145.253.193.190/@://meine.domain/openapi/@}}
145.253.193.190

LeeB · 17 Jun 2019

Du bist echt Gold Wert!! Via Rudi natürlich. Ergebnis (mich laust der Affe):

Connection failure: http://api.klicktel.de/gigasetpb/1.0/search.php?command=get%[.....usw.....]

Als nächstes den redirect string anpassen..

LeeB · 17 Jun 2019

Nach Anlegen der Ordner + kopieren v. search.php funktionieren im Browser sowohl:

Code:

{+redirect{s@://api\.klicktel\.de/gigasetpb/1\.0/search\.php@://meine.domain/api.klicktel.de/gigasetpb/1.0/search.php@}}
api.klicktel.de/gigasetpb/1.0/search.php

als auch

Code:

{+redirect{s@://api\.klicktel\.de/gigasetpb/1\.0/search\.php@://meine.domain/api.klicktel.de/gigasetpb/1.0/search.php@}}
145.253.193.190

Im fon immer noch "Dienst nicht verfügbar". Unterschied zu bislang: die Fehlermedlung kommt *sofort*, vorher erst nach 10 Sek. suchen.

@er13 , wie sähe denn der "cloaked/ masked" redirect aus analog zum https filter von dir, so dass http://api.klicktel.de/gigasetpb/1.0/search.php direkt auf meine.domain zeigt?

(und schick mir gern deine email-Adresse per PM so dass ich dir etwas € senden kann)

[EDIT]: tssss.. von "Foren/ VoIP-Hardware/ Gigaset / LDAP, Verzeichnisdienst":

Für das Klickte Telefonbuch wird http://api.klicktel.de/gigasetpb/1.0/search.php aufgerufen

..

er13 · 17 Jun 2019

Könntest Du bitte ein komplettes Beispiel inkl. aller Parameter für die URL posten, die aufgerufen wird und ebenso ein komplettes Beispiel inkl. aller Parameter so wie Dein Ersatzserver, diese erwartet (kein usw. bitte)?
Bist Du Dir sicher, dass das "Dienst nicht verfügbar" an dem falschen URL-Umschreiben liegt? Kann es sein, dass das (XML-)Format der Antwort nicht das richtige ist? Die Antwort kommt ja sofort, also scheitert es nicht an irgendeinem Timeout. In dem von Dir verlinkten Thread ein paar Posts weiter werden 2 cgi-Scripts beschrieben, eins für klicktel und eins für gigasetnet. Bist Du Dir sicher, dass Du auch bei dem von Dir verwendeten php-Script nichts verwechselt hast, sprich das dem gigasetpb entsprechende verwendest?
Wozu brauchst Du bei http (ohne s) einen "cloaked/masked" redirect? http- und https-Aufrufe funktionieren anders (GET vs. CONNECT mit anschließender direkter Kommunikation). Mein Gefühl sagt mir, es ist nicht notwendig. Mit größerer Wahrscheinlichkeit liegt es an etwas anderem (s. den vorigen Bullet-Point). Ansonsten sollte mit Hilfe von privoxy möglich sein, bei http (ohne s) die Antwort umzuschreiben und zu suggerieren, sie käme von einem anderen Server. Aber da müsste ich mich auch erst einlesen, auf Anhieb wüsste ich es nicht.
Danke fürs Spenden wollen. Ich persönlich brauche nichts, Du kannst aber gerne was fürs Freetz-Projekt spenden, bei dem ich einer der Entwickler bin. Hier findest Du den Link.

LeeB · 18 Jun 2019

prima dankeschön er13, mache ich. Ich bin grad wieder auf Achse und kann mich in ein paar Tagen wieder melden.

LeeB · 21 Jun 2019

Hallo @er13, bin wieder zurück. Erstmal sehr gute Nachricht - 50% Erfolg: kurz bevor ich losfuhr kam noch ein Anruf v. einer Firma, die NICHT in meinem lokalen fonbuch gespeichert war, und der Name wurde dennoch korrekt angezeigt (so wie in dasoertliche.de). Wenn ich aber nach einem Namen + Ort via Gigaset/ Netztelefonbuch suche, läuft sich die Suche tot. Also liegst du sehr warsch. richtig damit, dass entweder Roland Greim (tigerxy)'s php Script (für Gigaset C610 IP, C610A IP, SL400, N510 IP Pro) oder das von Steffen Lange (stelas aka filewalker2000) für sein Gigaset C430 A GO erweiterte Script, das neben dem Namen auch - falls vorhanden - die Adresse zurückgibt) für mein DL500A umgeschrieben werden muss, so dass die XML-Antwort das richtige Format hat.

Ich benutze grade direkten Zugriff auf oertliche.php auf unserem Server via der versteckten (nicht zugänglich via Gigaset Web-UI, grrmpff) URL im Gigaset, um rewrite/ redirect Fehlerquellen auszuschließen.
[UPDATE]: Sowohl Steffen als auch Roland haben mit Screenshots bestätigt, dass auf deren Gigasets die versteckte Seite die genau gleichen persönlichen Einstellungen widerspiegelt, die sie auf der Telefonbuch Seite in ihren Gigasets gemacht haben (das Modul das in meiner Web-UI fehlt). Also sollten bei mir Einstellungen, die ich auf der versteckten Seite mache, relevant sein.

• klicktel vs. gigasetnet cgi-Scripte: sowohl Roland als auch Steffen haben ihre Scripte anhand der Dokumentation von Gigaset erstellt und tragen in Ihren Gigasets NUR die URL zum Script ein. Falls dasoertliche cgi oder ähnliches benutzt, geschieht das auf deren Server.

• CONNECT (https) vs. GET (http): OK; gut zu wissen, also grade nicht relevant.

• Hier jetzt via Privoxy log die verschiedenen Netz-Telefonbuch Suchen + die Bedeutungen der Kürzel:

fn: Vorname
ln: Nachname
ct: Ort
st: Straße
hm: Telefonnummer (Privat)
nr: Hausnummer
mb: Telefonnummer Mobil
sip: Sip (VoIP) Nummer
zc: PLZ
prid: private phonebook number (optional)
lang=2 : DE (optional)
? first=1: ? man sollte meinen first = immer 1?
count=16: max. Anzahl an Ergebnissen

Gewähltes fonbuch Im Gigaset / Suche nach NN "Mann", Ort "Leer" außer im CH fonbuch:

2019-06-21 14:44:30.328 2ac8a520 Header: scan: GET http://api.klicktel.de/gigasetpb/1.0/search.php?command=get_list&type=pb&prid=0&fn=*&ln=Mann*&ct=Leer*&st=*&hm=*&nr=*&mb=*&sip=*&zc=*&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 14:44:30.329 2ac8a520 Header: scan: Proxy-Connection: Keep-Alive
2019-06-21 14:44:30.329 2ac8a520 Header: scan: User-Agent: DL500A/41.175.00.000.000
2019-06-21 14:44:30.330 2ac8a520 Header: scan: Host: api.klicktel.de
2019-06-21 14:44:30.330 2ac8a520 Header: scan: Accept: application/octet-stream, */*
2019-06-21 14:44:30.331 2ac8a520 Header: scan: Accept-Language: de
2019-06-21 14:44:30.331 2ac8a520 Header: scan: Accept-Charset: iso-8859-1,*,utf-8
2019-06-21 14:44:30.332 2ac8a520 Header: scan: Content-Length: 0
2019-06-21 14:44:30.333 2ac8a520 Header: The client connection can be kept alive due to: Proxy-Connection: Keep-Alive
2019-06-21 14:44:30.333 2ac8a520 Header: crumble crunched: Proxy-Connection: Keep-Alive!
2019-06-21 14:44:30.333 2ac8a520 Header: Adding: Connection: close
2019-06-21 14:44:30.334 2ac8a520 Header: New HTTP Request-Line: GET /gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 14:44:30.361 2ac8a520 Request: api.klicktel.de/gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048
2019-06-21 14:44:51.470 2ac8a520 Crunch: Connection failure: http://api.klicktel.de/gigasetpb/1.0/search.php?command=get_list&type=pb&prid=0&fn=*&ln=Mann*&ct=Leer*&st=*&hm=*&nr=*&mb=*&sip=*&zc=*&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048

2019-06-21 14:48:22.245 2ac8a520 Header: scan: GET http://tel.search.ch/api/siemens?command=get_list&type=pb&prid=0&fn=Thomas*&ln=Mann*&ct= &st=*&hm=*&nr=*&mb=*&sip=*&zc=*&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 14:48:22.246 2ac8a520 Header: scan: Proxy-Connection: Keep-Alive
2019-06-21 14:48:22.246 2ac8a520 Header: scan: User-Agent: DL500A/41.175.00.000.000
2019-06-21 14:48:22.247 2ac8a520 Header: scan: Host: tel.search.ch
2019-06-21 14:48:22.247 2ac8a520 Header: scan: Accept: application/octet-stream, */*
2019-06-21 14:48:22.248 2ac8a520 Header: scan: Accept-Language: de
2019-06-21 14:48:22.248 2ac8a520 Header: scan: Accept-Charset: iso-8859-1,*,utf-8
2019-06-21 14:48:22.249 2ac8a520 Header: scan: Content-Length: 0
2019-06-21 14:48:22.250 2ac8a520 Header: The client connection can be kept alive due to: Proxy-Connection: Keep-Alive
2019-06-21 14:48:22.250 2ac8a520 Header: crumble crunched: Proxy-Connection: Keep-Alive!
2019-06-21 14:48:22.251 2ac8a520 Header: Adding: Connection: close
2019-06-21 14:48:22.251 2ac8a520 Header: New HTTP Request-Line: GET /api/siemens?command=get%5flist&type=pb&prid=0&fn=Thomas%2a&ln=Mann%2a&ct=%0a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 14:48:22.251 2ac8a520 Request: tel.search.ch/api/siemens?command=get%5flist&type=pb&prid=0&fn=Thomas%2a&ln=Mann%2a&ct=%0a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048
2019-06-21 14:48:22.391 2ac8a520 Header: scan: HTTP/1.1 200 OK
2019-06-21 14:48:22.392 2ac8a520 Header: scan: Date: Fri, 21 Jun 2019 12:48:22 GMT
2019-06-21 14:48:22.392 2ac8a520 Header: scan: Server: Apache
2019-06-21 14:48:22.392 2ac8a520 Header: scan: Set-Cookie: myosotis=eedc11f7cede31a9ee586fce04367753; expires=Tue, 19-Jan-2038 03:14:07 GMT; Max-Age=586362345; path=/; domain=.search.ch; HttpOnly
2019-06-21 14:48:22.393 2ac8a520 Header: scan: Vary: Accept-Encoding
2019-06-21 14:48:22.393 2ac8a520 Header: scan: Content-Length: 1743
2019-06-21 14:48:22.394 2ac8a520 Header: scan: Connection: close
2019-06-21 14:48:22.394 2ac8a520 Header: scan: Content-Type: text/xml; charset=UTF-8
2019-06-21 14:48:22.395 2ac8a520 Header: Adding: Proxy-Connection: keep-alive

2019-06-21 15:07:52.573 2ac8a520 Header: scan: GET http://tuja.yoga/api.klicktel.de/gigasetpb/1.0/search.php?command=get_list&type=pb&prid=0&fn=*&ln=Mann*&ct=Leer*&st=*&hm=*&nr=*&mb=*&sip=*&zc=*&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 15:07:52.573 2ac8a520 Header: scan: Proxy-Connection: Keep-Alive
2019-06-21 15:07:52.574 2ac8a520 Header: scan: User-Agent: DL500A/41.175.00.000.000
2019-06-21 15:07:52.574 2ac8a520 Header: scan: Host: tuja.yoga
2019-06-21 15:07:52.575 2ac8a520 Header: scan: Accept: application/octet-stream, */*
2019-06-21 15:07:52.575 2ac8a520 Header: scan: Accept-Language: de
2019-06-21 15:07:52.576 2ac8a520 Header: scan: Accept-Charset: iso-8859-1,*,utf-8
2019-06-21 15:07:52.577 2ac8a520 Header: scan: Content-Length: 0
2019-06-21 15:07:52.577 2ac8a520 Header: The client connection can be kept alive due to: Proxy-Connection: Keep-Alive
2019-06-21 15:07:52.578 2ac8a520 Header: crumble crunched: Proxy-Connection: Keep-Alive!
2019-06-21 15:07:52.578 2ac8a520 Header: Adding: Connection: close
2019-06-21 15:07:52.579 2ac8a520 Header: New HTTP Request-Line: GET /api.klicktel.de/gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 15:07:52.579 2ac8a520 Request: tuja.yoga/api.klicktel.de/gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048
2019-06-21 15:07:52.905 2ac8a520 Header: scan: HTTP/1.1 200 OK
2019-06-21 15:07:52.906 2ac8a520 Header: scan: Date: Fri, 21 Jun 2019 13:07:52 GMT
2019-06-21 15:07:52.906 2ac8a520 Header: scan: Server: Apache
2019-06-21 15:07:52.907 2ac8a520 Header: scan: Upgrade: h2,h2c
2019-06-21 15:07:52.907 2ac8a520 Header: scan: Connection: Upgrade, close
2019-06-21 15:07:52.908 2ac8a520 Header: scan: Vary: Accept-Encoding
2019-06-21 15:07:52.908 2ac8a520 Header: scan: Transfer-Encoding: chunked
2019-06-21 15:07:52.908 2ac8a520 Header: scan: Content-Type: text/xml; charset=utf-8
2019-06-21 15:07:52.909 2ac8a520 Header: Adding: Proxy-Connection: keep-alive

2019-06-21 15:13:05.235 2ac8a520 Header: scan: GET http://tuja.yoga/api.klicktel.de/gigasetpb/1.0/search.php?command=get_list&type=pb&prid=0&fn=*&ln=Mann*&ct=Leer*&st=*&hm=*&nr=*&mb=*&sip=*&zc=*&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 15:13:05.235 2ac8a520 Header: scan: Proxy-Connection: Keep-Alive
2019-06-21 15:13:05.236 2ac8a520 Header: scan: User-Agent: DL500A/41.175.00.000.000
2019-06-21 15:13:05.237 2ac8a520 Header: scan: Host: tuja.yoga
2019-06-21 15:13:05.237 2ac8a520 Header: scan: Accept: application/octet-stream, */*
2019-06-21 15:13:05.238 2ac8a520 Header: scan: Accept-Language: de
2019-06-21 15:13:05.238 2ac8a520 Header: scan: Accept-Charset: iso-8859-1,*,utf-8
2019-06-21 15:13:05.239 2ac8a520 Header: scan: Content-Length: 0
2019-06-21 15:13:05.240 2ac8a520 Header: The client connection can be kept alive due to: Proxy-Connection: Keep-Alive
2019-06-21 15:13:05.240 2ac8a520 Header: crumble crunched: Proxy-Connection: Keep-Alive!
2019-06-21 15:13:05.241 2ac8a520 Header: Adding: Connection: close
2019-06-21 15:13:05.241 2ac8a520 Header: New HTTP Request-Line: GET /api.klicktel.de/gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048 HTTP/1.1
2019-06-21 15:13:05.241 2ac8a520 Request: tuja.yoga/api.klicktel.de/gigasetpb/1.0/search.php?command=get%5flist&type=pb&prid=0&fn=%2a&ln=Mann%2a&ct=Leer%2a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&reqsrc=user&limit=2048
2019-06-21 15:13:05.337 2ac8a520 Header: scan: HTTP/1.1 200 OK
2019-06-21 15:13:05.337 2ac8a520 Header: scan: Date: Fri, 21 Jun 2019 13:13:05 GMT
2019-06-21 15:13:05.338 2ac8a520 Header: scan: Server: Apache
2019-06-21 15:13:05.338 2ac8a520 Header: scan: Upgrade: h2,h2c
2019-06-21 15:13:05.338 2ac8a520 Header: scan: Connection: Upgrade, close
2019-06-21 15:13:05.339 2ac8a520 Header: scan: Vary: Accept-Encoding
2019-06-21 15:13:05.339 2ac8a520 Header: scan: Transfer-Encoding: chunked
2019-06-21 15:13:05.339 2ac8a520 Header: scan: Content-Type: text/xml; charset=utf-8
2019-06-21 15:13:05.340 2ac8a520 Header: Adding: Proxy-Connection: keep-alive

Als nächstes gilt es jetzt wohl herauszufinden, inwieweit eines der vorhandenen Scripte (am besten das von Steffen inkl. Adresse) für mein DL500A angepasst werden muss. Bester Ansatz ist wohl die Suche auf dem Gigaset via tel.search.ch:

Mögliche Eingabe-Felder:
Nachname
Vorname
Straße
Stadt

Ausgabe im Display:
Nachname, Vorname
Telefonnummer
Strasse Nr
Ort
Plz

• Spende: ✓

er13 · 26 Jun 2019

Code:

2019-06-21 15:07:52.906 2ac8a520 Header: scan: Server: Apache
2019-06-21 15:07:52.907 2ac8a520 Header: scan: Upgrade: h2,h2c
2019-06-21 15:07:52.907 2ac8a520 Header: scan: Connection: Upgrade, close

Mir sind bei Spoilern 3 und 4 die oben zitierten Zeilen aufgefallen (man beachte, die Zeilen gibt es nur bei 3 und 4). Neben dem falschen Format der Antwort wären die auch eine mögliche Erklärung, warum die Suche nicht funktioniert, wenn diese zu dem Erstzserver umgeleitet wird. Dein Apache fordert bei HTTP/1.1 Requests die Clients auf HTTP/2 zu "upgraden". Nicht alle Clients kommen damit zurecht (s. z.B. diesen Apache-Bug). Vielleicht gehört auch das Siemens-Telefon dazu. Schalte mal testweise "HTTP/2"-Support in Deinem Apache-Server aus und teste, ob sich etwas dadurch ändert.

LeeB schrieb:
• Spende: ✓

Danke! Haben wir erhalten.

Edit: Ansonsten scheint das Format der Anfragen, die gegen tel.search.ch und klicktel.de geschickt werden, identisch zu sein. Vergleiche doch die Antwort von tel.search.ch mit der Antwort der Ersatzscripte. Bastle Dir auch ein Hilfsscript und setze die Requests mit curl ab und nicht mit dem Telefon.

Und warum gibt es 2 verschiedene Scripte, wenn es nur eine Doku gibt? Worin unterscheiden sich die beiden?

LeeB · 26 Jun 2019

Hallo er13 - sinnvolle Tips!!

• HTTP/2 ausschalten: da die Domain ja auf einem shared webspace ist, habe ich das mit der .htaccess Methode versucht (1 | 2), aber leider bliebt der HTTP/2 upgrade.
Leider sind alle anderen Telefonbücher (NL/ DK/ NO) tot, so dass ich die nicht testen kann. Requests gehen aber alle mit HTTP/1.1 raus.

• Unterschied der beiden Scripte: beim erweiterten Script 2 (von Steffen, basierend auf Script 1 von Roland) werden noch Adressen (wenn vorhanden) mit ausgegeben. Das hat Roland einfach nicht implementiert.

• Requests via curl:

[2] Done type=pb
[3] Done prid=0
[4] Done fn=Thomas*
[5] Done ln=Mann*
[6] Done ct=
[7] Done st=*
[8] Done hm=*
[9] Done nr=*
[10] Done mb=*
[11] Done sip=*
[12] Done zc=*
[13] Done prid=0
[14] Done lang=2
[15] Done first=1
[16] Done count=16
[17]- Done mac=7C2F805E6EE3
[18]+ Done reqsrc=user

[2] Done type=pb
[3] Done prid=0
[4] Done fn=%2a
[5] Done ln=Mann%2a
[6] Done ct=Leer%2a
[7] Done st=%2a
[8] Done hm=%2a
[9] Done nr=%2a
[10] Done mb=%2a
[11] Done sip=%2a
[12] Done zc=%2a
[13] Done prid=0
[14] Done lang=2
[15] Done first=1
[16]- Done count=16
[17]+ Done reqsrc=user

(auf einem der anderen Gigaset macht es laut Rückmeldung nichts aus, ob die Übertragung der MAC-Adresse auf der EEPROM-Seite aktiv oder abgewählt ist.)

Als nächstes sollte ich wohl einen HTTP/1.1 Server ausfindig machen.

er13 · 27 Jun 2019

Bin über das, was in Deinem Post unter dem Bulletpoint "Requests via curl" steht, etwas verwirrt. Ich hätte eher sowas erwartet:

Code:

# existierender Name, die Erwartung ist es wird eine nicht-leere Antwort zurückgeschickt
curl -X GET 'http://tel.search.ch/api/siemens?command=get%5flist&type=pb&prid=0&fn=Thomas%2a&ln=Mann%2a&ct=%0a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048'

# nicht-existierender Name, die Erwartung ist es wird eine leere Antwort zurückgeschickt
curl -X GET 'http://tel.search.ch/api/siemens?command=get%5flist&type=pb&prid=0&fn=NonExistingFirstName%2a&ln=NonExistingLastName%2a&ct=%0a&st=%2a&hm=%2a&nr=%2a&mb=%2a&sip=%2a&zc=%2a&prid=0&lang=2&first=1&count=16&mac=7C2F805E6EE3&reqsrc=user&limit=2048'

<?xml version="1.0" encoding="UTF-8" ?>
<list response="get_list" type="pb" total="11" first="1" last="9" reqid="d702e906"><entry id="35b45195e39c44b1">
<ln>Mann</ln>
<fn>Thomas</fn>
<ct>Rümlang</ct>
<zc>8153</zc>
<st>Chilestieg</st>
<nr>22</nr>
<hm>+41432110156</hm>
</entry>
<entry id="b7b9aaef32b7c3f2">
<ln>Mann</ln>
<fn>Thomas</fn>
<ct>Selzach</ct>
<zc>2545</zc>
<st>Oberhaagstrasse</st>
<nr>28</nr>
<hm>+41326411062</hm>
</entry>
<entry id="0fd7b5128a061814">
<ln>Schenk (-Mann)</ln>
<fn>Thomas und Michèle</fn>
<ct>Thörigen</ct>
<zc>3367</zc>
<st>Bachstrasse</st>
<nr>21</nr>
<hm>+41629610483</hm>
</entry>
<entry id="68c8441fdea8988e">
<ln>Wild</ln>
<fn>Thomas</fn>
<ct>Richterswil</ct>
<zc>8805</zc>
<st>Chüngengass</st>
<nr>5</nr>
<hm>+41447841978</hm>
</entry>
<entry id="54445d7b19194334">
<ln>Mannhart</ln>
<fn>Thomas</fn>
<ct>Basel</ct>
<zc>4053</zc>
<st>Jurastrasse</st>
<nr>59</nr>
<hm>+41613611052</hm>
</entry>
<entry id="853d925285918685">
<ln>Mannhart</ln>
<fn>Thomas</fn>
<ct>Berikon</ct>
<zc>8965</zc>
<st>Grundackerweg</st>
<nr>57</nr>
<hm>+41565347844</hm>
</entry>
<entry id="ae8ccbf9c247dd1e">
<ln>Mannhart</ln>
<fn>Thomas</fn>
<ct>Netstal</ct>
<zc>8754</zc>
<st>Landstrasse</st>
<nr>52</nr>
<hm>+41556432038</hm>
</entry>
<entry id="663ca52b7d434883">
<ln>Mannhart (-Ammann)</ln>
<fn>Thomas und Sandra</fn>
<ct>Oberkulm</ct>
<zc>5727</zc>
<st>Römerweg</st>
<nr>3</nr>
<hm>+41628963686</hm>
</entry>
<entry id="e69ab996767bbfe6">
<ln>Mannhart</ln>
<fn>Thomas und Ursula</fn>
<ct>Neftenbach</ct>
<zc>8413</zc>
<st>Aspacherstrasse</st>
<nr>58b</nr>
<hm>+41523154848</hm>
</entry>
</list>

<?xml version="1.0" encoding="UTF-8" ?>
<list response="get_list" type="pb" total="0" first="0" last="0" reqid="e80b4f69"></list>

Das gleiche hätte ich dann gegen den Ersatzserver mit dem Ersatzscript abgesetzt. Wenn das Format der Antwort identisch ist, dann liegt es vermutlich an den Einstellungen des Ersatzwebservers (aktuelle cURL-Versionen sollten mit "upgrade: h2" umgehen können). Auf jeden Fall erst sicherstellen, dass das Format der Antwort das richtige ist. Und dann untersuchen, warum bevor die Antwort im richtigen Format kommt, der Webserver irgendwelche "upgrade: h2" verlangt.

Edit: dieses done in Deinem Post sieht mir danach aus, als hättest die URL nicht gequotet, die done's kommen von der Shell.

LeeB · 27 Jun 2019

Habe alles gelesen - antworten kann ich morgen Freitag.

LeeB · 9 Jul 2019

Aufgeschoben ist nicht aufgehoben.. Es liegt am Aufbau der .php Dateien - mein Gigaset braucht ein anderes XML-Format. Nummer wird korrekt zugeordnet und dargestellt inkl. Suche mit nur Nummer; Suche nach Name + Ort läuft sich tot.

Ich hoffe dass ich im Gigaset-Beitrag eine Suchstring-URL eines Gigaset bekomme, auf dem mit dem Netz-Telefonbuch auch die Suche nach Name + Ort funktioniert. Dann kann ich die php entsprechend umbauen.
(leider antwortet dort nur noch eine Person was die Sache etwas zäh macht)

er13 · 9 Jul 2019

Funktioniert denn die Suche nach "Name + Ort", wenn sie gegen tel.search.ch abgesetzt wird? Wenn ja, dann mache doch folgendes.

Stelle den Proxy im Telefon wieder auf privoxy ein und lasse privoxy alle Anfragen loggen, insbesondere die URLs.
Setze die Such-Anfrage nach "Name + Ort" gegen tel.search.ch ab.
Find im privoxy.log die entsprechende URL.
Setze mit curl dieselbe Anfrage ab und speichere die xml-Antwort.
Setze mit curl eine ähnliche Anfrage gegen Deinen Ersatzserver ab. Ähnlich bedeutet, wenn ich es richtig verstehe, lediglich eine Schweizer Stadt gegen eine Deutsche ersetzen (als Testnamen verwendest Du ja schon einen mit großer Wahrscheinlichkeit sowohl in der Schweiz als auch in Deutschland vorkommenden Namen). Speichere die xml-Antwort Deines Ersatzservers und vergleiche sie im Sinne des Formats mit der des Schweizer-Servers.

LeeB · 17 Jul 2019

danke er13, sehr plausibel! Ich gebe zu dass ich mich z.Zt. zwingen muss freiwillig viel am Computer zu machen.. entweder am Wochenende oder während dem nächsten Tiefdruckgebiet ..

URL umleiten (URL-Redirect) mit Freetz: bitte um Anleitung

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Statistik des Forums