I have a web app configured to persist logins if the user chooses. I am using formsauthentication and set cookielesss to autodetect. When cookies are used the ticket along with specifics about the user is properly maintained. When I disable cookies, I get the session identifier embeded in the url and directed to the login page.
However, I cant get the redirect to the default page to work using IIS 7. I get 400 Bad Request - URL
When I run the application in VS Using cassini the cookieless ticket and session work great.
I have tried the following:
set <httpRuntime maxUrlLength="15000"/> in web config.
Set the Request Filtering to allow for very long URL's (1000000)
When I authenticate and redirect in VS the redirect works and the URL looks like:
http://localhost:53605/(X(1)S(new25hbmvxqwiupj3uijv2et)F(HHRQfdcbjBvktt0SbfNrna7jUgMQYcA2q6uv8ptwjYoQCEIO3MgYD59wXfTdRPSnzdaoCnkKQF762Tiii98dEQdmUGiAYm5XrpIcwin_TcEWMRsHDIgrqsvULetKy97--XUWx3ESMkMRWNwwYNEoC65nqvG_-ip1g0y_9N52RwspzW__QFNberHNf9asniAQv8dtFkbClW8hKyjPYawaIzmLgFw-OfCVyVyIkrjONs7nu2TZCV7sQvgG-txTtiSJ_vtBYB81vbv3n2ZSrjHsft6zyodZh0yNbRGJUc1Vb0ee4iAJQnOJ-a4Plsgx1r3qwhw_dVhkl20Omr2V81o84sfhAhd_Ye0Y4CFJk8EakQ5yRf8GNQ7gyn5Je3RWqnoAiW_gdB7VMqB7-eX4RjTml4W1RJAN2QWa7S21w-A_KrD7oc1Cp6vAOwPt_kkBxhYTApUkPIsiFQ5kJ0RnPA6NJFal9BGD9JVS9YDHZS2MHQicR-kUang362AghpexjcIDPTE1QPTEslzfpB2RnoosTPunPK5a3L0_hwSwWllagbCHxHXEA_6d73UhFeX23QYzMG_1gYFhANj7vIT5e3nDuRL_6Yep22h8tzRKAly8mk3Ke5U1_lU0sMrgdjXIInnsVzCbLfN42rUVlJaGOM1kbzM68-P9bLvu_qyD1h1iZak_coDPPNpioxg1BTQ5fyon4kSd89qAvSoDslIn3xJxwCABeY63lKoElQjel1mkusI4i1woGww_wDhS6jvFGP3R-d7xJtpTNiXsNvBc-ZIrca_XF1Z-YDnGCTy6v85vCTj-aU4xPcj7eW4CHSFwLslsBjjvNbH6UAHT5YtFW6KTlXY15_KBp79cIqOqKIOD6HRjtHijiJkgEC_BU6KPFPZh5kDH1kPX3c0wg1cFAreFM_BLje2s7MErA4kBvTwRQJMbaShFv8QOcABxLAFscw1iFBSu7QjeT0ugDblc53PCwTrlLAs5X7KTDyHgRvcGvkGKvWmFdlzD3WHLtJRlbrgDfDbYI0rWDKkR6-K2Bg--VAuUs-HBRM0FFUb0znnwaKE52Hjr39xWE1CiWmkQrcEkNhDdo-_LCnnJbXCWYiwV8rtJcFjRvISsz2w7avIJDRiGEOKw3odAL5FXztHMcLMHMuQ-wiE1LXh0FmdbSd7goHNK6Ehmoda8FP2mzN2DZEIEx887F_HO9xjQcVlHRlnECvphvBRax6jkmmJ7VUGrYLM2zH7T9MTGtuTUTASxfpvp7IYq49NhytYEieoTqDuPYVxpT7_ACywrkOZOnHUeuTvKFfDuCofE1IH_QfnB1lBk29u2qvKJMSHP5Xb1aAsZ-9_dMVIN0klVZIqvby6Khw2))/Home/Dashboard.aspx
When it fails in IIS the url looks like :
http://localhost/Reports/(X(1)S(4a0qmf3mf5ebpgokpyog0beq)F(xQGpHp6u9P7tD7I5D8uLI7zZRylqaqssOk_930NAk5VlyED4DYAk5eAC-uPOwHl5EKUrILTmQYTTIiiELL1ILCdQ5EG1gRLsIR5wSIS5_EjW0ibRstbvXVPsdSZxQOT4Uwj-JjauRvTAYNWSdff0H3mvANX8mAfUhSuMKjy67HhGJZkQjFPqUYtll0xSdP8RJ-0lMzQ-uCWG9b2OiRPT35HRk6AiuKQPDUWZNjMRzKO9-NSfm_SQXHhq8wr4xbNXuBmyDmME1lpxl3BhB_Y86KZjl_9eklFOJ-oz8_dmyuEbZqvMzXYTSfC6sL95UlRfxgXkBHRdNzLdqvMD3_1Ke78fAKEEuE6JeUbEXpES76Q6M3NJpxwz1YlEMoC_PgV9s5EQtX65QZbxzML2kSyst38Eu_WLyCL-KKE3gAmEHSUhfZ1G5WXXOoSk__vgz1Od9SNUfjxsIyEK4-HstZMLGDNWXZZc7_DTlPGrXS6yr6NfjmJEixxKEpgP-HN3Q18YPyOcS5EUwGa3tISPjGKMGq5qmZcRyihwAImUA0X5lh-rgNvWNM5AkPK8F7fAzygNJ7CZMmKN87wiCsC8kDthKZrOhbzgO4EOTsv0gEnSe7wiSH4vWzrEumUrJDGrFGLmtudyl4hLgAwQcSdMh2OIapGNVAPQTwEqwqc4kEZnWpGxXrfPxejG-IH391TFqHLyYWkN5onVXWhOn3cCeYNqD0yc7jgOZ_AY4gTj4UtiB_PAK4jlRhwyQ4SozJzkSQFimtURC-H6Z7piB6ekXIihtAdTURTpaq6CmKefCh6ydgDJNywS9nFoFBKPUdi3kF9hpuz9yNtfz8zh4LAm6ikP2p0yXBpecQq2W7V6XFJhVXC00Hvx56kvks-r1V4660-WDsvee86-4GID1XBcM7AoOWfkvABWMRDLjixk8ud57QlyJ_kYmHTeIQWDuj3EA1a6383ffycVdx3AFJ8px3eNacHybKX-9kwoYJaoo_T019ZvrcgrNWeK4uEf3VRVYVRydkJoW4Pk6OgDRN1LvSYkwEjGiN_m2g03MLfpboLMtGzorBSjTwvId8u_CqqBB4QAqj7Vt4htU6jfKWlERlqo38dTdub0i69eLAJffVoTEH2wIhqIpRp6WIWk8NNh97AkqYAOR5744cNuqJBJI56ZsY7Ja31wPArJI4nO1ey49CzReI3W5I9MWW2TuWE3x2XjFxXbea_4uTv5CdhGOYqsd5IugFMLz-0Rcva77ZI-ZipISwzv62ZXAGaQKg6PuVWIEGtTs9K_B-h3Dhg3anjxNOS7t03U6v4d9lyNwtmN4nK4-29NUAf2DcPo7V4TQzc-TtTpv-4gcvA_U47HijfasQ2))/Home/Dashboard.aspx
The only difference is the webdev server loads the application at the web root. I tried adding a blank test page to ensure there are no resources outside of the page being requested and it still fails.
Any suggestions?
Related
My website uses MVC ASP.NET and Entity Framework user roles. The website also requires SSL for every page access by design. Thus, call the site example.com which can only be accessed as "https://example.com" or "https://www.example.com". Port 80 is configured to never respond. All pages work fine, except a main page link which can only be accessed when a user is already logged in. If the user is not logged in yet, moving the cursor over the link shows an https:... prefix is assumed to that link, but the [Authorize] attribute specified in the C# code at the top of the MVC controller action causes redirection to the login page without an https:// prefix. Rather than redirecting to https://example.com/..., redirection goes to example.com/... thereby leaving out the https prefix and causing a hang to the site that requires SSL for all pages.
I'm using MVC5 and OWIN on top of an older application that was developed with ASPX pages.
I'm using an Application Cookie, and that expiry seems to work fine, and using <Authorize> attribute on my MVC controllers protects them just fine. However, I also have a session timeout to handle.
Unfortunately the application is using iframes, and when I have a session timeout or a cookie timeout, only the given frame that was accessing a protected resource redirects to the login page. Essentially, I get the login page inside one of the iframes instead of redirecting the whole site to the login page.
Is there some standard way of handling these timeouts (either cookie or session) so as to redirect the whole browser to the login page instead of just one iframe?
I have an ASP.NET 4.0 WebForms site that is running on a IIS6/Server 2003 instance. The site itself does not permit anonymous access and uses IIS basic authentication before the user can get to the Forms authentication screen. However, there are two site nodes below the site level, that are virtual directories which DO permit anonymous access (for requesting static images by other machines).
A new request required me to route those requests to a different page and examine the URL being requested and perform different tasks. I’m using a MapPageRoute method in the Global.asax file and the route clears through Forms authentication with a web.config setting <allow users="*" />. Obviously, that works great locally, but when deployed to the IIS6 machine basic authentication kicks in before the request gets routed.
Is there a good way to "fake" or create a virtual directory node in IIS6 and grant it anonymous access so that the routed url request can execute?
This might not work for everyone, but since in my case HTTP Authentication was primarily instituted just to prevent people from multiple attempts at the login page, I actually removed Basic Authentication from the site and all virtual directory nodes.
Then I added it just to the ~/[loginpage] that was being used. Since forms authentication was in use all unauthenticated users are re-directed to the login page and then get the basic authentication. Since the routed page request needed to be public I just added it as an exception to the Web.config. The routed values have to meet a very strict criteria to even be executed by the page logic and everything else is returned as a 404 by the handler.
Obviously this means that the asp.net dll is executing before IIS basic security when requests are redirected to the login page, but in this case I think it is fine.
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 an application we bought that I need to integrate, and it uses jakarta connection to get to the application from IIS.
So, the basic operation is:
user goes to the url
Gets redirected to the application
SSO is enabled, so redirected back
to IIS for fetching of domain
credentials
Back to application
If username is blank show login
page, else let user in.
This is a simplification of all the steps, but the basic idea is here.
My difficulty is that I need both Windows Integrated Auth and anonymous on, as some users won't have credentials, and need to be prompted for a username/password.
I have looked at: IIS Windows Authentication before Anonymous already, but the user doesn't get to click on a link to decide. The application goes back to IIS looking for login.aspx and from there I want to either get their domain credentials or pass back to the application empty strings to signify that there are no credentials.
It seems this isn't going to be possible though as if anonymous is on it doesn't make the 401 request so the credentials aren't passed.
If I can't get this to work with just using an ASP.NET page, could it be done using an ISAPI filter, or a module?
UPDATE:
I found a possible solution, but I need to figure out how to get it to work, as my login page is on the JBoss server.
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx
Keep the Authentication in the IIS as the Anonymous.
When loading the home page check the ACTIVE DIRECTORY for the current logged in USERNAME if exist
provide the extra functionality to current user or else with fewer options.
Refer --> Active Directory Cheking