search

zdavatz / AmiKo-iOS

AmiKo Desitin für iPhone und iPad
https://apps.apple.com/ch/app/amiko-desitin/id687642725
GNU General Public License v3.0
1 stars 2 forks source link

Authorisation Error (Access) #163

Closed zdavatz closed 1 year ago

zdavatz commented 1 year ago
  1. When trying to login to ADSuisse, even if I am not logged in, I always get:
  2. IMG_698BCF1923C1-1
  3. Tested on two iPhones and one iPad.
zdavatz commented 1 year ago

For Test, this URL works: ENABLE_EPRESCRIPTION=true ./certifaction server --api https://api.testnet.certifaction.io --hin-api https://oauth2.sign-test.hin.ch/api

Lets try this for PROD: ENABLE_EPRESCRIPTION=true ./certifaction server --api https://api.certifaction.io --hin-api https://oauth2.sign.hin.ch/api

zdavatz commented 1 year ago
  1. 2023-06-14-3 Getting Started CI EPD - Technische Beschreibung-V81.pdf
  2. https://oauth2.ci-prep.adswiss.hin.ch/samlService/saml (pre prod fürs testing, die verwendete HIN ID fürs Testing muss uns bekanntgegegen werden, da sie speziell geflagged werden muss)
  3. https://oauth2.ci.adswiss.hin.ch/samlService/saml (prod)
zdavatz commented 1 year ago

Gemäss Rücksprache mit Aaron muss der Fehler bereits vor dem AD-Swiss Aufruf passieren.

Im angehängten iOS Screen sehen wir nur den Rumpf der URL. Wäre es möglich, die gesamte URL zu sehen? Wir vermuten den Fehler in dieser URL. Wie sieht die return_uri genau aus? Wurde diese zur Freischaltung beantragt und auch freigegeben?

Die sollte in etwa so aussehen: http://apps.hin.ch/REST/v1/OAuth/GetAuthCode/ADSwiss_CI?response_type=code&client_id=myprivateid&redirect_uri=http%3A%2F%2Flocalhost%2FgetAccessToken

ios_screen

zdavatz commented 1 year ago

Sign Error: sign_error

zdavatz commented 1 year ago

@b123400 says: Guten Tag, es scheint, es ist unmöglich die URL zu zeigen, aber wir benützen “amiko://oauth” und “comed://oauth” für unsere Return-URL Was ich weiss wollen: Warum ist es manchmal klappt? z.B. Falls unsere Return-URL schlecht ist, dann sollt es immer Error geben?

zdavatz commented 1 year ago

Now getting this: IMG_7412

zdavatz commented 1 year ago

Ich konnte zwei Rezepte erstellen über den certifaction.ywesee Server, auch der Verify Befehl hat funktoiniert und beide Rezepte wurde als gültig angezeigt.

Ein Fehler von mir heute Morgen zusammen mit dem Screenshot von gestern hat mich jetzt die Idee gebracht, dass möglicherweise bei einer konfigurierten URL noch die Test-URL drin ist? Das sind die Steps, die ich durchführe um das auth handle zu holen:

Steht im Code nirgends ci-pred oder ci-test drin?

Auth step 1: get the oAuth2 access token: Open in Browser (will launch HIN authentication) http://apps.hin.ch/REST/v1/OAuth/GetAuthCode/ADSwiss_CI?response_type=code&client_id=ch.hin&redirect_uri=http%3A%2F%2Flocalhost%2FgetAccessToken

output -> GUB2AvHL...aozQ4ghhY (90 Tage gültig)

Auth step 2: get the oAuth2 bearer token: curl --location --request POST 'https://oauth2.hin.ch/REST/v1/OAuth/GetAccessToken' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=authorization_code' \ --data-urlencode 'code=GUB2AvHL...aozQ4ghhY' \ --data-urlencode 'redirect_uri=http://localhost/getAccessToken' \ --data-urlencode 'client_id={...}' \ --data-urlencode 'client_secret={...}'

output -> b#G7XRWMzXd..LnxAj#GpN7V

Auth step 3 - restart here after auth handle expiration (2h idle/12 total validity) get the SAML URL: curl --request POST --url 'https://oauth2.ci.adswiss.hin.ch/authService/EPDAuth?targetUrl=http%3A%2F%2Flocalhost%2Fsuccess&style=redirect' --header 'accept: application/json' --header 'Authorization: Bearer b#G7XRWMzXd...aMALnxAj#GpN7V'

(return value: {"url":"https://ci.adswiss.hin.ch/samlService/saml/authenticate?guid=_1f115509-92b2-4a3f-beea-7b2332fd35dc","epdAuthUrl":"https://ci.adswiss.hin.ch/samlService/saml/authenticate?guid=_1f115509-92b2-4a3f-beea-7b2332fd35dc"}) output -> https://ci.adswiss.hin.ch/samlService/saml/authenticate?guid=_a1f089eb-c42e-4712-bb95-a61b211bb376

Auth step 4 - get the auth code -> paste URL in Browser with incognito mode>will ask for HIN ID

(return value in Browser URL location: http://localhost/success?auth_code=FJdOA..3MR) output -> FJdOA..3MR

Auth step 5 - convert the auth code into auth handle curl --request POST --url "https://oauth2.ci.adswiss.hin.ch/authService/EPDAuth/auth_handle" -d "{\"authCode\":\"vzut..Q2E6\"}" --header "accept: application/json" --header "Content-Type: application/json" --header "Authorization: Bearer b#G7XRWMzX...nxAj#GpN7V"

(return value: {"authHandle":"wD69kL1...WKBP"}) output -> auth handle: wD69kL1...WKBP

zdavatz commented 1 year ago

Ah… Ich denke, Ich weiss das Problem. Das Auth Handle ist “2h idle/12 total validity”, aber ich habe nur “12 total validity” überlegen, nicht “2h idle”!

z.B, wenn man das Auth Handle jede Stunde benutzt, dann kann er auf 12 Stunden verlängern. Aber wenn ist für 2 Stunden nicht benutzen, dann es ist nicht mehr gültig

zdavatz commented 1 year ago

should be fixed with: https://github.com/zdavatz/AmiKo-iOS/pull/171