Máte pravdu. Content-type je v odpovědi application/json. Nedokážu říct, proč to funguje s Accept:"/", ale s Accept:"application/json" to vrací 406.

Dobrý ten, tady je provider file, který používám: https://github.com/deltazero-cz/next-auth/blob/main/packages/core/src/providers/seznam.ts V configu pro Auth potom: ... providers: [ Seznam({ clientId: process.env.SEZNAM_CLIENT_ID, clientSecret: process.env.SEZNAM_CLIENT_SECRET, scope: 'identity,contact-phone,avatar', profile: (profile) => { ... }, }), ... ] ... A šlape to dobře

Tak už jsem to rozjel, díky za pomoc!

Zdravím mam dotaz zapomněl jsem heslo k emailu když chci změnit heslo ta tam mam staré telefoní číslo dokázaloby se s tím něco dělat ??

Jo dobre

vyreseno, posilal jsem spatne data, diky!

Dobry den, dokumentace od pocatku zminuje vyhradne e-mailovou adresu, ktera je zamyslena jako unikatni identifikator. V budoucnu v teto veci mohou nastat principialne dve zmeny: pole "account_name" prestane byt funkcni (existujici, overenou) e-mailovou adresou; pokud se tak stane, budeme o tom s predstihem informovat (a tuto skutecnost dale zminime nekde v datech odpovedi) pole "account_name" prestane byt unikatni. Dle meho nazoru je toto vyrazne mene pravdepodobne, nez predchozi bod. Pokud by tato neprijemna moznost nastala, tak o tom budeme taktez informovat a zaroven nabidneme nejake dalsi pole, ktere bude unikatni.

Dobry den, problem by mel byt opraven. Pokud by se i nadale projevoval, dejte vedet.

@Lukáš-Langr Dobrý den, posunuli jsme se nyní do stavu, který navrhujete -- pokud použijete PKCE, není nutné posílat client_secret. Budete laskav, pokud to ozkoušíte a ověříte.

Podelali lidi falešní dubi smluvní pododi

Prectete si odpověď v spodni odpovědi.

Jsem rád, že se tohle téma řeší, protože mám delší doby stejný problém. Prosím o řešení

Dobrý den Pane Hlavsa email vy musíte zrušit v nastavený účtu.

UA:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0

Ano, je to povinny parametr. A musi byt identicky tomu, ktery byl zadan u predchoziho presmerovani na /api/v1/oauth/auth.

Paráda, díky!

Dobry den, pokud mate na mysli volani /user, pak toto nenasleduje zadny konkretni standard. Polozky jim vracene jsou popsany na https://vyvojari.seznam.cz/oauth/doc. Nektere z nich jsou "pro usporu casu" vlozeny taktez do odpovedi na /token, ale stale je to nase vlastni rozsireni -- RFC 6749 se o nich myslim nijak nezminuje.

Ahoj máš Jak 🥰

Dobry den, jsou to insider informace, nebot implementace Prihlaseni pres Seznam je tak nejak v me kompetenci. Ale z komplikovanych historickych duvodu tady na foru vystupuji pod soukromym uctem. Nejsem si jisty, co znamena "nepožaduje call back serveru přijímajícího autorizaci". Budete laskav, kdyz to trochu upresnite. Skutecnost je takova, ze Seznam nabizi OAuth a nikoliv OIDC, to je cele. Jestli se to do budoucna zmeni, to neumim odhadovat -- aktualni reseni dovoluje treti strane delegovat prihlaseni na Seznam a ziskat potrebna data o prihlasenem uzivateli. Dalsi navysovani miry komfortu partneru by jiste bylo mile, ale fakticky a technologicky nikoliv nezbytne. Verim, ze veskera data, ktera o uzivateli Seznam timto zpusobem nabizi, je mozne ziskat i bez pouziti OIDC/JWT.

Dobry den, problem jsem vyresil. Byl zrejme v nepodporovane verzi TLC. Diky