[C#] Asp.net MVC Facebook login probleem

[Laurens-R]

Hallo allemaal,

Ik ben momenteel bezig met een implementatie van een facebook login. Op een gegeven moment redirect ik naar de volgende url:

code:

https://www.facebook.com/dialog/oauth?client_id=<appid>&redirect_uri=<returnurl>&scope=<permissies>&response_type=token

so far so good: Ik redirect naar facebook, kan daar netjes inloggen en facebook redirect netjes naar de opgegeven url.

Daarbij worden ook een aantal extra query string parameters meegegeven (zoals de access_token; best belangrijk)... maar deze staan achter een hashtag ipv een vraagteken. Gevolg: mijn mooie controller die ik had opgegeven als return url krijgt de parameters niet door omdat alles na de hashtag op webserver niveau doodleuk genegeerd word.

Mijn google zoektochten leiden ook niet tot veel; vaak komt het neer op 'dikke pech; zo werkt IIS/asp.net niet' ... maar het lijkt me toch niet dat ik de eerste zal zijn met dit probleem.

Ik laat hem nu returnen naar een alternative view waarin javascript de request aanpast (door simpelweg wat aanpassingen te doen/cookies zetten) en window.location op eerder genoemde controller zet.

Dit brengt echter ook weer de nodige problemen met zich mee. Het liefst zou ik direct binnen willen komen op de controller.

Heeft 1 van jullie al eens hier mee geworsteld of uberhaubt iets gedaan met hashtags in een url?

[Nibble]

Kun je de parameter met de hashtag niet stringsplitten zodat deze apart kan worden uitgelezen?
Kun je hem anders uit de request hengelen?
Of misschien kun je ipv responsetype token, code gebruiken?
Zomaar wat suggesties...

[Laurens-R]

Code ipv token gebruiken heeft hetzelfde effect

want ook de code word achter een hashtag meegegeven in de url en word dus genegeerd door de webserver.

Als ik de rawurl van de request opvraag, is de hashtag en alles wat daarachter komt verdwenen.

Van de parameters is geen spoor meer te vinden in m'n HttpContext.

[Megamind]

Ik denk dat je beter kan overstappen op de JS API, die biedt meer mogelijkheden en officiële support. Je roept dan via JS het login gebeuren aan en het resultaat kan je de posten met een ajax call naar je controller.

[Laurens-R]

Dat word even uitvogelen wat voor impact zoiets heeft op m'n architectuur, maar ik ben bang dat ik daar idd niet aan ontkom.

Ik ga even verder met deze uitdaging en laat nog wel weten wat het is geworden

Update:

Rekening houdende met de afgesproken architectuur heb ik besloten om via een aparte view (wat de return url is geworden voor Facebook) de window.location.hash value in een cookie te zetten. Dan wijs ik de window.location naar mijn controller en lees ik server side mijn cookie uit.

ik weet het ... het stinkt een beetje... maar de impact op de architectuur zou een stuk groter zijn en dus vanuit een kostenoverweging maar voor deze aanpak gegaan...

[ Voor 55% gewijzigd door Laurens-R op 16-05-2013 13:35 ]