I'm setting up an Instagram feed component for a client, and as part of this we need to pull in data from the client's feed (I know there are plug ins that will do this, but we need a very specific layout and in addition most of them seem to work by scraping, which is against the Instagram T&C's).
So, I have it all working in terms of it redirects you to the Instagram authorisation window and if you click "allow" that sends you back to the auth controller I've set up.
I've set the Auth redirect up as an API controller as it should only ever be viewed in the back office; however, I then need to somehow redirect the user back to the custom dashboard they were previously on (or I suppose I could direct them back to some page that has the data they need on - they only need to see the long-lived access token, which I'll be storing in the DB and refreshing every few days).
Actually maybe that's the answer - should I just have a front end page that's protected from "normal" public view and ask the user to log on as a Member to see it after redirect, or is there some way I could redirect back to the back office dashboard from the server side controller after it gets the auth page? (I can easily redirect it to e.g. the root of the Content editing node, but that's no use).
Maybe a protected page might be the best way to go....thoughts, ideas? I know this sort of functionality exists in Uno, but I don't have access to that :).
I'll answer my own question...this might be specific to Instagram and my eventual solution, but somebody might find it useful.
In the end I realised I needed a new node type to store the Instagram settings (the client will have multiple Instagram accounts and each needs its own access token to work on the site); however, Instagram doesn't let you submit a username or give the user any choice about which account they're allowing access to, it's always the logged in account (as long as it's a test account on the FB app they have to create for this).
So I created a new "Social Media Feed Settings" doc type, where the Instagram client Id and secret etc. are stored, along with a child type that stores the username (for display), the long-lived access token and expiry date.
When the user adds an Instagram account in the back office they have to give the user name; I submit this to a controller, and create one of the new child nodes via the ContentService with just a username before redirecting the user to Instagram's Authorisation window (you have to do this to get the code that lets you get the short lived access token that you can use to get a long-lived access token).
When the auth request comes back, I look for the new node (it should be the only one without an access token) and store the access token and expiry date before redirecting the user back to the new node in the back office via:
"/Umbraco#/content/content/edit/[newNodeId]"
We won't go into the pain of actually getting an Instagram access token, which takes about 5 times as long to code as the code for actually getting the media once you have the token....!
Getting back to the backoffice after Instagram Auth
Hello Umbracians!
I'm setting up an Instagram feed component for a client, and as part of this we need to pull in data from the client's feed (I know there are plug ins that will do this, but we need a very specific layout and in addition most of them seem to work by scraping, which is against the Instagram T&C's).
So, I have it all working in terms of it redirects you to the Instagram authorisation window and if you click "allow" that sends you back to the auth controller I've set up.
I've set the Auth redirect up as an API controller as it should only ever be viewed in the back office; however, I then need to somehow redirect the user back to the custom dashboard they were previously on (or I suppose I could direct them back to some page that has the data they need on - they only need to see the long-lived access token, which I'll be storing in the DB and refreshing every few days).
Actually maybe that's the answer - should I just have a front end page that's protected from "normal" public view and ask the user to log on as a Member to see it after redirect, or is there some way I could redirect back to the back office dashboard from the server side controller after it gets the auth page? (I can easily redirect it to e.g. the root of the Content editing node, but that's no use).
Maybe a protected page might be the best way to go....thoughts, ideas? I know this sort of functionality exists in Uno, but I don't have access to that :).
Thanks!
Chris.
I'll answer my own question...this might be specific to Instagram and my eventual solution, but somebody might find it useful.
In the end I realised I needed a new node type to store the Instagram settings (the client will have multiple Instagram accounts and each needs its own access token to work on the site); however, Instagram doesn't let you submit a username or give the user any choice about which account they're allowing access to, it's always the logged in account (as long as it's a test account on the FB app they have to create for this).
So I created a new "Social Media Feed Settings" doc type, where the Instagram client Id and secret etc. are stored, along with a child type that stores the username (for display), the long-lived access token and expiry date.
When the user adds an Instagram account in the back office they have to give the user name; I submit this to a controller, and create one of the new child nodes via the ContentService with just a username before redirecting the user to Instagram's Authorisation window (you have to do this to get the code that lets you get the short lived access token that you can use to get a long-lived access token).
When the auth request comes back, I look for the new node (it should be the only one without an access token) and store the access token and expiry date before redirecting the user back to the new node in the back office via:
"/Umbraco#/content/content/edit/[newNodeId]"
We won't go into the pain of actually getting an Instagram access token, which takes about 5 times as long to code as the code for actually getting the media once you have the token....!
is working on a reply...