I am trying to integrate my Rails application within another application using the "iframe" technique.
The hosting application has an iframe like that:
<iframe src="http://10.0.0.106:3000/" width="800" height="500">
</iframe>
This frame retrieves and displays the login page, which is ok. But when I type in username and password to login, it seems that authentication fails and I am prompted again for login. Note that no normal "Wrong username/password" message appears (as it is done when I give wrong username of password). The login form is displayed as if it were the first time I visit it.
Any clue?
If the CSRF token is included on the page the only problem that you should experience with iframes is this IE weirdness :
http://www.sympact.net/2008/07/rails-and-ifram.html
Is the iframe being served from another domain? This is probably a security feature.
You could turn off the security feature (probably a bad idea), or try other methods of authentication.
"Yes. It is served from another domain."
— Comment above.
Reason why you are not getting an error message is because the authentication doesn't fail. The cookie that's being stored is for '10.0.0.106:3000' and not your current application. I wouldn't be using an iframe to handle authentication. (Why are you doing this anyway?)
Related
I've implemented mixed mode authentication in our MVC 5 application and everything seems to be working fine apart from one niggly problem.
When I browse to the site in Chrome the following page is displayed:
This site can’t be reached
The web page at xxxx might be temporarily down or it may have moved
permanently to a new web address.
ERR_UNEXPECTED
The main page is actually loaded, but I'm concerned that this might confuse users. The error doesn't appear in Firefox, IE or Edge.
I'm assuming it's down the redirects I'm performing during the login process, but I'm not sure why Chrome is showing the error.
The basic process is:
Forms authentication process checks if user is logged in
If authenticated, redirect to desired page (or default)
If no, redirect to signin action
Signin action then checks if single sign on is enabled, if it is then the user is redirected to an area of the site which can handle windows authentication. Otherwise they are redirected to the normal login page
User is then either authenticated using windows authentication, or redirect to login page
Just looking for any ideas as to why this error is only shown in Chrome
I ran into the same behavior with chrome briefly displaying the above error before loading the page. I narrowed it down to a chrome issue while handling the http2->http1.1 downgrade caused by using windows authentication (HTTP2 doesn't support windows authentication).
I ended up working around the issue by disabling http2 on the server. No real downside in my case since all the sites were behind windows authentication so the connection was always being downgrade to http1.1 anyways.
The following chrome bug has more detail.
We have an application that is using ADFS for authentication. For the single signout we are redirecting the application to the url https:///adfs/ls/?wa=wsignout1.0.
The Application gets redirected to the URL without any issue but the signout is not working in INternet explorer. In Chrome and Mozilla this single signout is working fine without any issue.
Has anybody face this issue and what was the workaround?
How do you detect that "sign-out does not work"? I guess, what happens is:
you call https:///adfs/ls/?wa=wsignout1.0 and sign-out actually takes place
you visit a Sharepoint page again and IE does not ask you the user credentials, letting you in at once. But this is OK, because at this moment a new sign-on automatically takes place. (You probably may notice that when you revisit the SharePoint page there is a roundtrip to ADFS visible in the browser's address bar).
Actually, from your post, I believe it is working correctly from everywhere. However, since you are using IE and likely on a domain joined machine you are silently signed in with desktop SSO (i.e. windows integrated authentication). For example, if you signed in from outside your corp network on IE and then signed out and signed-in again, you will see the behavior to be different.
Thanks
//Sam (Twitter: #MrADFS)
I do have the same issue. As mentioned, it is an expected behavior when we sign out from within the network. On an external network, you should be prompted for credentials after redirecting to sign out URL. However, it doesn't work in Internet Explorer and Edge.
It does work fine in Chrome and Firefox. The only work around I found is to clear the cookies manually on the IE browser and then redirect to sign-out URL. However, it's hard to expect end user to clear their browser cache manually.
Regards
Prasad
I'm about to build a console application that needs access to the authenticated YouTube Data API. Calling the API's themselves is not a problem, I know quite well how to make and process HTTPS requests.
I've already gotten the API key and the Client ID. No problems there, either.
The problem is the authentication.
I've checked here: https://developers.google.com/youtube/v3/guides/authentication#installed-apps
On the "Installed applications" tab, in step two, it instructs on how to set up a url to call to do the authentication step. All good so far. But before programming anything, I thought I'd try and see what that url does in the browser.
Turns out it just displays a login prompt. Well how about that. That won't work in this kind of console application. The idea is, presumably, that the user is somehow shown this webpage and be instructed to login and allow access. Then, somehow, by some kind of magic perhaps, the access token is sent back to my console application.
Two things I'm not quite sure about:
1) How do I prompt for the username and/or password in the console app and send that to the authentication URL?
2) How would I get the access token back from it?
The biggest problem is that the API seems to require a browser... Which isn't there. My console application will (eventually) run unattended, so starting up a browser and displaying a webpage and doing nothing until it returns a code, is out of the question. I need to somehow supply the authentication page a username/password and get back the code right away.
I'm working on an app using facebook & oauth. The app lives inside a facebook canvas, and the authentication is done server side. The app is done w/ Ruby on Rails 3.2, using Koala for dealing with the api (and mongodb as backend, for what it's worth), and hosted on heroku.
So, I supply the heroku url as redirect_url for the callback. Which makes the user go out of the canvas after the authentication, and well, I want it to stay inside. I read a few threads about this that suggested I redirect to the canvas url with js once the authentication is done. I did that, but now it seems that my session token is never set, and the user goes through the auth flow every time he tries to see a non-public page (which means he loops on the welcome page, having an "invisible" exchange with facebook each time).
I don't really get what I'm doing wrong here, so any help is welcome. If you need more informations, just ask.
Thanks for your time!
So I found what was my problem : the page my canvas pointed to was a "public" page, and did not handle anything authentication related, meaning it didn't parse the signed_request, or anything else. I ended up setting a special endpoint for the canvas in charge of handling the signed_request logic, and now it works as one would expect.
I've got a local HTML + Javascript file that consumes a JSON API. I'd like to authenticate users via Facebook, but I'm not sure if that's possible -- does anyone have experience with this? I'm unsure of how the redirect (back from Facebook) would be managed when we're serving from a file:// context.
Just do it! :)
And you'll see.
PS
Maybe you should encode some characters like ":", "/" etc
Unfortunately, it won't work from a file:// context for a couple reasons:
In most modern browsers, Javascript cookies won't work with the file:// protocol, which is how you would probably authenticate your users. This can be solved by hosting the page using http:// from localhost.
In order to log a client in using facebook, you need a registered facebook app, and to register your facebook app, you have to give facebook a static domain where your app will be hosted. This is to ensure that requests for your app come from your domain and not from an attacker residing at a different domain.
Last but not least, because your users have to authorize your app on facebook.com, you also need to specify a redirect url after their successful login, which would be very challenging to circumvent.
it won't work under file:// context.
as James said, authentication through facebook requires your have a hosted web page and also register your site as facebook app; and also , facebook will need to redirect the browser to a so called "callback" url, which must be a http:// web page.
you can choose to host your webpage in a local web server instead