SL TravelplannerV3_1
Hej Support
Jag har pratat med Håkan Östlund som bad mig skicka frågan till er
Idag fungerar inte den gamla urlen längre försökte med den nya men det går inte så bra se försöken nedan.
Bytt ut min key mot x
Skickar gammal länk som fungerade i går klockslag:240321025216
api.sl.se/api2/TravelplannerV3_1/trip.json?key=XXXXXXXXXXXXXXXXXXXX&originId=9192&destId=125&date=2024-03-29&numF=6&time=06:00&Products=72&passlist=1&destWalk=0&originWalk=0
fick som svar 6 trips
Försöker i detta nu med
journeyplanner.integration.sl.se/v1/TravelplannerV3_1/trip.json?key=XXXXXXXXXXXXXXXXXXXXXXX&originId=9192&destId=125&date=2024-03-29&numF=6&time=06:00&Products=72&passlist=1&destWalk=0&originWalk=0
första gång får som svar
{
"serverVersion": "1.4",
"errorCode": "INT_ERR",
"errorText": "internal error"
}
får som svar tredje gång
{
"error": "Quota has been exceeded"
}
Vad gör jag för fel
Mvh Peder
Jag har pratat med Håkan Östlund som bad mig skicka frågan till er
Idag fungerar inte den gamla urlen längre försökte med den nya men det går inte så bra se försöken nedan.
Bytt ut min key mot x
Skickar gammal länk som fungerade i går klockslag:240321025216
api.sl.se/api2/TravelplannerV3_1/trip.json?key=XXXXXXXXXXXXXXXXXXXX&originId=9192&destId=125&date=2024-03-29&numF=6&time=06:00&Products=72&passlist=1&destWalk=0&originWalk=0
fick som svar 6 trips
Försöker i detta nu med
journeyplanner.integration.sl.se/v1/TravelplannerV3_1/trip.json?key=XXXXXXXXXXXXXXXXXXXXXXX&originId=9192&destId=125&date=2024-03-29&numF=6&time=06:00&Products=72&passlist=1&destWalk=0&originWalk=0
första gång får som svar
{
"serverVersion": "1.4",
"errorCode": "INT_ERR",
"errorText": "internal error"
}
får som svar tredje gång
{
"error": "Quota has been exceeded"
}
Vad gör jag för fel
Mvh Peder
Följ inlägget
3
följare
SL har tyvärr genomfört ett oväntad breaking change för en månad sen. De 4-siffriga id:er som används i exemplet i inlägget måste översättas till en annan form. Först paddar man med nollor tills man får ett 7-siffrigt id i formen ABCDEFG. Sen skriver man om id:et enligt följande mall, akta att de första två siffer byter plats: 3BA1CDEFG. 9192 blir alltså 0009192 vilket blir 300109192. Dessa nya id:er returneras från platsuppslag-API:et och närliggande hållplatser.
Vi håller på med att förtydliga detta i dokumentationen.
SL har inga nivåer längre i det nya API:et, utan endast 1 nivå där det finns rate-limiting per minut. Jag vet inte exakt vart gränsen går, men det verkar gå bra att göra 1 anrop var 5e sekund.
Hälsningar,
Bert
HUR skall man hålla sig uppdaterad på dessa kritiska förändringar??
Liten undran tidigare innehöll Product.name på Waxholmsbolaget Båtens namn ex "Söderarm" nu får man "BÅT 1673" också en förändring som jag vill få en förvarning om
Mvh Peder
För kritiska förändringar som URL-bytet skickades det ett mejl. De andra förändringar har varit oväntad, även för oss, vilket har gjort att vi inte har kunnat kommunicera ut allt hur vi vanligtvis skulle göra.
I det här fallet har SL angett att det inte skulle vara några skillnader, men har det ändå skett vissa förändringar, och det här (båtnamn för Waxholmsbolaget) är antagligen ett specialfall som har missats när det testades.
Hälsningar,
Bert
Förändringen i API:et ställer till med lite spratt för mig.
Behöver hjälp med att felsöka. Jag kör från en Win7 maskin.
VB.NET webclient har använts utan problem tidigare.
Får ojämna svar tillbaka från anrop.
Normalfallet skall det bli så här:
{"Trip": [{"ServiceDays": [{"planningPeriodBegin": "2024-01-09","planningPeriodEnd": "2024-05-23","sDaysR": "täglich","sDaysB": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"}],"LegList": {"Leg": [{"Origin": {
Ibland blir det så här:
‹í\ÝRÛJ~—‹‹œ* æO©¢ÊNø '(p6›Ú:µ%¤1h12G’³áÄ\î+ìíÞìÖy‚ððbÛ#YX#˶¶‘±ÄÖh4š™þ¦Õóu«Ô[žs][ûÛú)÷¾9ß6oü¨àºcº®ãžsÏéÚïø¹ã‰:A„m ¼ŒúzªÎŽkk(„B _4x"Šƒ‡ÿžwë".Ü….5¢oÖš×^|æ8³;þg;ú¨ßþ¶^?àçŽ
Hypoteser som jag behöver förstå om de inverkar:
1) Jag försöker göra tre anrop med 1 sekunds mellanrum. När jag ökar till 5 sekunder verkar det funka, men känns inte säkert.
Finns det någon begränsning? Var går den?
Varför får jag konstiga bokstäver tillbaka på mitt anrop och inte ett annat fel. Mystiskt.
2) Har tidigare anropat med https men går endast med http nu
Har ni skrotat en TLS nivå i samband med API förändringen?
Hade samma problem med SMHI en gång, men de kunde återställa TLS 1.1 (tror jag att det var)
Tack!
Jag vet inte vilka TLS nivåer som fanns tidigare, men på den nuvarande server är det bara TLS 1.2 och 1.3 som är tillgängligt. Många har redan slutat stödja TLS 1.0 och 1.1, och stöd för dessa äldre format har redan tagits bort från bland annat Firefox och Chrome.
Har din dator för nuvarande inte stöd för TLS 1.2 är det bättre att få igång TLS 1.2 på din dator än att lägga till TLS 1.1 till API:et. I vissa riskbedömningar kan stöd för osäkra protokol anses vara en svaghet, vilket gör att det nog inte återaktiveras.
För att få igång TLS 1.2 på Windows 7 kan du kika här: https://support.microsoft.com/sv-se/topic/uppdatera-f%C3%B6r-att-aktivera-tls-1-1-och-tls-1-2-som-standard-s%C3%A4kra-protokoll-i-winhttp-i-windows-c4bd73d2-31d7-761e-0178-11268bb10392#bkmk_easy
Hälsningar,
Bert
Jag har dubbelkollat. TLS 1.2 var redan aktiverad.
Vet vi att den versionen är kvar i api:et?
I så fall förstår jag inte vad problemet är.
Använder System.Net.WebClient()
Mvh,
Bob
Jag har fastnat och behöver er hjälp. Får TLS fel.
Den senaste uppdateringen fungerar inte som tidigare.
"System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.Net.Http.HttpClientHandler.GetRes"
Windows 7
TLS 1.2 aktiverat, 1.1 avaktiverat
.NET 4.6 och 4.8
CLR 4.0
Tusen tack,
https://test-tls12.messagemedia.com
men inte till
https://journeyplanner.integration.sl.se
api.sl.se
fungerade fint förr.
Följande ciphersuites finns enligt ssllabs:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA)
https://www.ssllabs.com/ssltest/analyze.html?d=journeyplanner.integration.sl.se&s=18.244.214.87&hideResults=on&latest
Det borde funka med tex Firefox på Windows 7, så det är möjligt, men det verkar inte funka med internet explorer på Windows 7. Beroende på vilken bibliotek som .NET använder under ytan kan det alltså vara att .NET på windows 7 inte har stöd för dessa protokoll. Lösningen är i så fall att använda en tredjepartsbibliotek som själv har implementerat krypteringen.
Hälsningar,
Bert
När SMHI uppgraderade 2021 var det exakt samma typ av problem, som de sedan åtgärdade.
Jag citerar mig själv:
"Så här bedömer jag status:
· SMHI uppgraderade TLSstandard till 1.2. och 1.3. Det var i sig rekommendabelt.
· Dessvärre har endast tre skiffer kopplats till 1.2, vilket ställer till med problem.
· Ingen av dem stöds av Windows 7 och det går inte att lägga till fler på klientsidan i .NET
· Det stänger ute en ganska stor maskinpark från tillgång till SMHIs öppna data.
Den enklaste och säkraste lösningen på problemet är sannolikt att lägga till ett av följande skiffer på serversidan:
· TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) Forward Secrecy
· 256
· TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) Forward Secrecy
· 128
· TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Forward Secrecy
· 256
· TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy
· 128"
Jag är inte riktigt kompetent nog att förstå skillnaderna med de som du listade, men det kan nog de som ställt in servern
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA)
Jag föreslår följande:
- jämför med https://www.ssllabs.com/ssltest/analyze.html?d=opendata%2ddownload%2dmetfcst.smhi.se&latest
-se om det inte går att lägga till något skiffer till. Från min lista ovan eller från de som SMHI valde. Det var mycket enkelt för SMHI att göra och tillräckligt säkert.
Bert, jag förstår att det inte är du som gör dessa ändringar. Kan du hjälpa mig komma i kontakt med rätt personer för enklast problemlösning efter APIbytet?
Tusen tack!
Vi kollar med SL om detta är möjligt.
Hälsningar,
Bert
Tack
ssllabs säger att IE 11 / Win 7 inte kan ansluta pga "Protocol or cipher suite mismatch".
Mainstream stöd för Windows Server 2012 R2 slutade i 2018, och extended support slutade i oktober 2023. Jag skulle rekommendera att använda externa bibliotek, som tex Curl, så att man kan koppla upp sig på ett säkert sätt även om systemet inte längre blir uppdaterat.
Hälsningar,
Bert
```
var startInfo = new ProcessStartInfo
{
FileName = "curl",
Arguments = "-H \"Accept: application/json\" \"https://transport.integration.sl.se/v1/sites/9186/departures?transport=METRO&forecast=60\"",
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true,
StandardOutputEncoding = Encoding.UTF8
};
using (var process = new Process { StartInfo = startInfo })
{
process.Start();
string result = await process.StandardOutput.ReadToEndAsync();
process.WaitForExit();
return result;
}
```