I host a webapp which includes other webapps via iframes. Every webapp has its own domain. It looks like this:
webapp.com main webapp
│ first.webapp.com embedded into a view in webapp.com via iframe
│ second.webapp.com embedded into a another view in webapp.com via iframe
│ ... and so on
Every webapp uses the same Keycloak server for user authentication.
So, when the user logs into main application, he is redirected to Keycloak and - after successful login - back to the webapp with an authorization code, which is then exchanged for tokens. When I open an iframe, it follows the same procedure, but instead of asking the user to login, it just makes the both redirects, since the user is already logged in to Keycloak.
Now I observe a very strange behavior: when I clear ALL my browser data (history, cookies, cache, ...), log in into webapp.com and open the iframe of first.webapp.com, the Keycloak server is prompting me to log in again within the iframe. It doesn't matter which iframe (first, second, ...) I open, in every iframe I need to log in again. After logging in again (within any iframe), I can use every iframe without logging in again, even if they have different sources.
When I log out, close the browser and restart the whole procedure, there is never a second login prompt again (only the first login is prompted). It only happens when I clear all the browser data (or a new user starts the webapp). Even when I delete all cookies/storage & session data from all the webapps and Keycloak, it never asks for the second login.
Can anyone give me a hint on what to check to figure out whats happening here? I guess that Keycloak verifies that webapp.com is allowed to include first.webapp.com in an iframe. I configured the CSP of the Keycloak server by adding the sources of all webapps. So that's not the actual problem.
Related
I want user will not redirect to login page on closing website or browser once user is loggedIn.for this i use localStorage. it is working successfully but, it works after page rendering in nextjs. so, it give me error for 5 seconds. i want to access localStorage before page rendering in nextjs.[![First image shown when website is launch
Local Storage is only available in the browser. It will not be available on the server (or while the page is doing any kind of server-side operation).
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
You should use a cookie to store this information if it needs to be accessible by both the server AND client.
Our ASP.NET application is hosted in IIS 7.5 and has the following setup:
main site is hosted under root IIS folder accessible with http://siteurl (1)
we have a separate app in the same AppPool hosted under http://siteurl/Intranet (2)
Main app (1) has Anonymous Authentication enabled along side Forms Authentication (url: siteurl/loginform).
Second app (2) has Integrated Authentication (NTLM).
The login procedure works as following:
User goes to siteurl first
User gets redirected to /Intranet to check integrated auth
If integrated is accepted user gets redirected back with proper auth cookies to siteurl and gets access to the site
If integrated fails user gets redirected to siteurl/loginForm to manually fill in credentials
We have some issues with Internet Explorer (8, 9, 10) that refuses to submit the form data at step 4. It appears to be a known behavior that IE will not POST content to an unauthenticated site once the NTLM negotiation started for that session. I have considered some workarounds for this:
store credentials in a cookie (with JS) and on the server if the POST content has 0 length try to check the cookie values. delete the cookie afterwards
send credentials using GET instead of POST (ugly as we need to make sure the user does not see his just posted password in the browser address bar)
Provide a link to the user to open a new tab and continue the auth process in a separate browser session (this seems to work as IE will happily send POST data from a second tab)
Are there any other options we might have to get around this issue?
From the above 3 which one would be preferable and what unconsidered pitfalls we might encounter?
I wrote about this issue here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Your question omits important information which makes it hard to troubleshoot. You should never see the problem described with the literal URLs you've used, because IE uses protection spaces to decide whether a site is going to demand credentials via a HTTP/401 and example.com/ and example.com/foo/ are different protection spaces.
It would be very helpful if you could share a Fiddler log of this scenario for better troubleshooting.
I need to find out the base URI of an ASP.NET Web API application hosted in IIS 7.5+, right after the app's startup, but before any client request may have reached it. The scenario where I need this is the following: a periodic check is performed, through a timer that runs independent of user requests and which is triggered together with the app startup (same process); if this check passes certain conditions, some registered users will receive an email containing a hyperlink to my web application. Now, I don't want to hardcode that link anywhere, but rather get it dynamically from the web application itself. It would be simple to figure it out from inside the context of a client request and then cache it in memory but, as you can imagine, the timer might go off before any request reaches the server.
How could I then determine correctly the application's base URI? I was thinking the most appropriate place would be the Global.asax.cs file, during the web app's startup, yet i couldn't find anything that looked helpful.
Given a full URL such as "http://mydomain.com/MyApplication/Controller/Action", you can get some of this information from the System.Web.Hosting.HostingEnvironment.ApplicationHost object. You can get the following:
ApplicationVirtualPath -> "/MyApplication"
SiteName => "Default Web Site"
However, you will not be able to get the domain name before an actual request comes in. This is because an IIS website can accept requests for many different domains, some of which are only known via DNS and never configured anywhere.
For example, your website could respond to both mydomain.com and www.mydomain.com. Which is the correct one that you want to put in your link?
You can configure your IIS website to only accept connections that request a particular host, but that cannot be retrieved from an ASP.NET application.
I have an asp.net app. It has a page that requires authentication. The authenticated user can view the page because he/she is authenticated. The page makes a jQuery Ajax call to a WCF service. The WCF service checks that the user is authenticated via HttpContext. I have a user that is using WinXP and IE8. This user can authenticate to the page, but when the Ajax call is made from the page to the wb service, the user recieves my "session not authenticated" message on the page, generated by the service and displayed on the page. When I use the same OS/browser combo, the page and service work just fine, as expected; no errors.
What option in this user's IE settings would cause this behavior?
It turns out that I was just being stupid and was violating the "same origin principle". My service was at mydomain.com and my user was probably on a page at www.mydomain.com. The service would fail because the domains didn't match completely. So, I setup some re-write rules on the server so that no matter what variant of the domain that was requested by the browser, it would always re-write to www.mydomain.com. Then, I simply set the the service call to the that domain (or in this case, just used window.location.hostname), and all problems were resolved. Big "D'oh" moment.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)