I have an ASP.NET site which requires a login to get access to the rest of the site. Login information is stored in database and accessed through a service.
The business have asked to be able to login from an external site. I added a Generic Handler (.ashx) to my project which takes username & password input, verifies the credentials, and then if they are valid stores the credentials in the session using IRequiredSessionState interface. It then gives a URL of the entry point to the application to the client.
The client (a plain old HTML page using jquery to .post()) then takes the response and redirects to this URL.
Well, this seems to work great and exactly what I needed. I figured that I could avoid having to generate a token and pass it around in the querystring by doing this, since the handler and site both share the same session. But the problem now is when I tried a test by putting the Login HTML page on a co-workers computer (eg external to hosting in my application) - it doesn't work. The session is added correctly in the ASHX handler, but in the Page_Load of the entry point, that session value is gone..
Is it possible to do what I am doing? Why is session forgot immediately like this? I would think it would be the same as logging in from the log-in page and redirecting from there (it's the same application & the same session..)
Thanks!
Related
I use MVC5 for a site where users have to login with custom credentials. I've changed the login procedure from the inital auto-generated code to a somewhat single page approach.
Users enter their credentials
these are sent via ajax to the controller
if the credentials are valid, a loading animation shows and the main page is being loaded via ajax
the controller that returns the main page is annotated with the [Authorize] attribute.
I wonder: is there something basic that speaks against such an approach?. The site I run does not have any top secret contents, but it should not have a backdoor just because I missed something basic here.
From what I could see, MVC5's auto-generated login procedure sents the credentials in plain text as well, just like the ajax post I use. The auto-generated login includes a RequestVerificationToken which I obmitted.
Thanks for any ideas!
Using AJAX to authenticate a user is a common approach. A couple things I would recommend:
Whenever you are sending credentials like a username/password combination it should always be done via SSL. Even after the user is authenticated all requests should be send over SSL to prevent a hacker from stealing the security token.
Make sure that there are is no UI code in your AJAX calls. AJAX is used for sending and retrieving data only. Your UI should be on the client using a framework such as Knockout, Backbone, or Angular. Even if you are not doing a full blown SPA (Single Page Application) and do not require one of those frameworks, select a client side templating framework like Mustache or Handlebars.
I've got a Active Reports Handler configured on my website so that i can open the Report directly over a link e.g.
http://localhost/Report.rdlx?OutputFormat=pdf
The problem now of course is that there is no authentication so that everyone can call this link.
How can I add authentication check to this handler?
I am using Forms authentication, preferably I'd like to also check if the user is in a certain role, but would be happy with IsAuthenticated check - so that the user at least has to be logged in to see the report.
I tried to build a "reverse proxy" route handler (I'm using MVC) that returns the response from the report URL only if the user is authenticated. But this doesn't solve the problem since the "original" URL is still exposed.
Any Ideas?
You can still use the ASP.NET authorization control, meaning you can limit access to that location in the web.config file
http://support.microsoft.com/kb/316871
Technology
ASP.NET, VB.NET 2.0 (soon to be 4.0)
Overview
I'm writing a Login / Authentication Portal, so that a web application can use it to login a user, and then they can use the application using their credentials.
The login portal will be a separate application, and initially only available via an extranet as well as intranet for certain applications; but future apps will need to authenticate via the web (happy to implement as a separate instance). I basically want other individual applications to be able to authenticate users via this portal.
So that...
A user goes to an application's web url (i.e. www.application.com / http://apps/application - intranet) and clicks "login".
User's browser is redirected to the portal application, with a query
string
www.loginportal.com/login.aspx?url=www.application.com/login.aspx
(or other page).
User fills in their credentials (username, password), and clicks
"login" button.
Browser redirects back to url i.e. www.applications.com/default.aspx or login.aspx and is authenticated and logged in; and can use app.
Completed
I have the authentication itself sorted, and will implement as a class library in the local applications via a dll.
Need
So I basically need to know, how to:-
1. Post data to the portal url (could be different domain).
2. Redirect browser with post.
3. Make sure that the authentication is secure, and not easily hackable (I know how to use urlencode and htmlencode etc) - just not sure about implications of posting data across domains.
Any help greatly appreciated...
Cheers,
Duncan.
Seriously tough stuff, here. If it were me, I'd lean heavily on Windows Identity Foundation. I believe it can support this scenario (haven't actually done it; someone else at my company is developing against it).
OK, so this is the solution I ended up using:
In the original application (the one that needs the authentication; step 1 above) I redirect the user to my login portal, and include the original url as a get parameter.
The user then types in their details, username and password.
Next, the server-side code authenticates them, and redirects to a new page, where I send back to the page an html form which includes the request datetime (for security) along with a encrypted string (including the datetime of the request) of the data I want sent back to the original form.
I also add a JavaScript post method which sends the data to the original url as a form post. Because I'm using the same class library at both ends, I can encrypt and decrypt the data using the same method and the original requesting application has all the user data, including the ability to check the datetime of the request (I allow a set amount of time between the authentication and the picking up by the original app, making sure these are within say 5 minutes.
And job done.
If anyone wants the code, I can provide it, just don't have it with me at the moment, if I remember I'll post it.
Not the most elegant solution, but it works, and it's secure, so I'm happy. :).
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.
A client of mine is needing their current website to tie into an online leasing module off site.
The module needs to be accessed from our website by posting the username and password hash to it, or the registration information.
It works when I copy the view state manually from the source into the form they fill out on our system, but not when I pull it from a WebClient Request.
When I use the WebClient to pull back the viewstate, for some reason, the viewstate never changes.
With each visit in IE though, the viewstate does changes.
Why are you dealing with viewstate? You could authenticate by using WebRequest, get authentication cookie from WebResponse and use this cookie with each next request.
We were able to force them into submission and create a web service for us to use and a web page that takes a hash to log the user into their system.