I have an ASP.NET MVC 3 website which is available both from a specific public url, and I'm also making be available as a Facebook App.
Inside my website logic, in some places I have to determine whether the current request is from the Facebook-app, or from the public website, because I want to display content based on this environment.
So, for eg. if the user is using my site as a facebook-app, then I want to display a picture, and if the user is using my site normally, then I don't wanna display a picture.
To determine whether I'm from a Facebook app, I check the "signed_request" in the HttpContext.Request, and store it in the HttpSession to be available for my other actions, not just for that action (url) which is defined for my Facebook app.
So when a child-action is executed, I can determine based on the Session, that the website is used as a FB-app or not.
The problem happens, when the Session times out, because then althought the logic is still running inside Facebook, my logic thinks it's not inside Facebook.
Any advice?
Can you periodically contact the server from the FB-App? Maybe you can "ping" from it if the user does not make any action for a while
If you don't want it, you can store important information from signed_request in cookie, that expires when browser is closed. Session is not reliable enough to store this content.
I think your approach may be wrong. What if user enters your application both on Facebook and from separate url? Facebook has Javascript API, that places cookies if user is connected to the site. If user is connected, you should display Facebook related content and it shouldn't matter if this is canvas app or separate page. Specially if it uses the same views. If views are not the same, only url, you should have separate urls for canvas app.
Last solution, but horrible is to check in Javascript if page is working in iframe and if it is and signed_request is not present, reload top.location.
Related
I'm trying to authorize a spotify user in my windows forms application. I am able to make a GET call to the web API, and I get a response back that is HTML. When loaded into the browser, this HTML is a login page, but my question is two parts.
1) What would be the best way to display this login page. Obviously if I could launch the browser and have it return the authorization code somehow, that would be best, which brings me to my second question.
2) How would I get the authorization code from the browser when I launch the login screen? I can't see a way that my forms application would be able to receive any information after the login screen is launched. Sorry if this seems obvious.
I figured it out, the URL I was using was not meant to be requested from, but to have the user navigate to in their browser. I basically just put the link in my application as a button and it would launch in chrome. Once the user logs in, I used http://httpbin.org/get to display the authentication code and just copied the code into my app as a temporary fix. Obviously this is not ready for release, and I am still working out how to get the code from the redirect url to my application, but it's a step in the right direction!
1) You can display a web browser inside your form to do the login part.
2) Browsers like Chrome can't return values. You could look at the data sent / received from your browser and search for an authentication token or something like that
Can we somehow get the curret state of website where the bot is embedded as IFrame?
As in for example, the bot validates whether the user is logged in or not, or his login credentials. Hence, I should be able to pass user's account id along with some other info as well into the bot's code. Then, accordingly, the bot displays the options differently.
I've seen such bots implemented on Industry Websites using bot framework itself.
So, any idea how to work this around?
Hence, I should be able to pass user's account id along with some
other info as well into the bot's code. Then, accordingly, the bot
displays the options differently.
Use webchat's backchannel functionality. You will have to switch from the basic iFrame to a few more lines of code, but it's working well.
Change the webchat implementation on the front side
Add the post of an activity to send the necessary information (still on the front side)
Get this activity on your bot side and handle it
See my other reply around this functionality here:
How do I get the locale in conversationUpdate activity?
I should be able to pass user's account id
You can pass the user's id and name using the embedded code.
<iframe src='https://webchat.botframework.com/embed/bothandle?s=YOUR_SECRET_HERE&username=YOUR_USER_NAME&userid=YOUR_USER_ID'></iframe>
To pass details other than the user id and user name you need to use the backchannel method in the web-chat repo. Here is a sample doing the same.
While it is possible to access the parent page from IFrame using JavaScript's window.parent, I doubt that it is the ideal approach. A better solution would be to expose an web API that would provide the required data, which would the bot's code call to access required information.
Platform: ASP.NET 4.0, VS 2010
My scenario is this
I have the credentials of an external website
I do a couple of GET/POST to scrape some data off of it
Depending on something that I find, I want to give my user a hyperlink that, when clicked, takes him 3 levels deep into the target website beyond the login page
Of course, I could just provide a URL to the top level on the target site, and he would click through to get there. But is there a way, via ASP.NET, that I can programmatically login and then open the page on a separate window/tab?
I think that, to have the user avoid the login, you're going to have to scrape that page and present it to the user yourself. If you pass the user along to the page at all then he's going to have to authenticate against it. Your application on your server authenticated, but the user in his browser did not. Unless there's some strange (and terribly insecure) quirk about the destination page, it's not going to trust that the user is you.
I have a silverlight application that requires the user to login.
The problem is when you hit the refresh button on the web page it reloads the site, and requires the user to login again.
What I want it to do is act like ASP .NET where the user will remain logged in for 20 minutes even if they hit the refresh button.
What mechanism is ASP .NET using to achieve this? Does it use session variables for instance, and how does it expire after 20 minutes?
Thanks.
ASP.NET is doing this on the server side using various methods. The most simple, it could be cookies. Typically people use the session state feature. A sliding scale is used to store update times.
Though you could do it on Silverlight using something like isolated storage, it won't be secure: the isolated storage isn't encrypted and is on the local system, vs. with ASP.NET, where the server can store this information where it is secure.
As to what to store: you really don't want to. You should let your user log in, which hits a web service on the host. Then you just rely on the ASP.NET or other server-side authentication system. You could create a "perma-cookie", but that's just duplicating functionality that already works.
In addition to storing something in the IsolatedStorage you can also access the cookies used by the page. If you store an authentication token in your cookie then you can just pick it up from the silverlight app. This page and this page may get you started.
Right now, I have all the employees of my company login to an external website using the company id, username and a password. We are trying to integrate it into an intranet portal which should provide seamless access to this website without requiring the user to enter these credentials.
Is there any way of doing this programmatically (.NET C#)? Very similar to screenscraping, Can I simulate the appropriate POST action and then redirect the user to the logged in page?
Any help is appreciated.
Thanks.
You can make a <form> in your page that mirrors the external site's login form with the same action= attribute, then fill put and submit it using Javascript.
Note that this requires that you send the user's password to the browser, which is never a good idea.
You can certainly post to the external website, the tricky bit will come when you redirect the user there, because there'll be cookies restrictions I think.
You might be able to do something with Javascript that makes the Client browser post directly to the third party with the correct credentials, look into jQuery's Post command.
Assuming that the external website maintains sessions with cookies in some way, the problem is, your company website can't set a cookie, except from it's own domain, and the 3rd party website can't read cookies except from it's own domain, so you can't transfer or pass the cookie across to your users.
The name for this technique is Single Sign-On. There's no one way to do it, but the emerging standard is called SAML. This requires participation on both parts (the originator and target website), so it's probably beyond your current purview.
Like the other two answers have mentioned here, you can post a formatted request directly to the action of the login script, but I can tell you from experience that that solution will be brittle, that is, it will shatter the second the target website makes any changes.
Your best bet is to contact the administrator of the target website and ask if they have an SSO (Single Sign On) solution.