I'm trying to implement a web-view web part in sharepoint that will load up a small 'widget'y type thing I've got hosted on our local IIS. I desire to only show this web part to particular users, but cannot use the 'target audiences' feature of Sharepoint as we only use Foundation an the feature isn't present.
I'm currently attempting to use Windows authentication on the page, and it works fine for allowed users seamlessly infact - however, I was hoping there was a way if the user is denied, they don't get a popup asking for credentials, it would just redirect them to a blank page, thus the web part 'doesn't show' for them.
Is this possible using Windows authentication or do I need to use forms authentication against Active Directory and make them use a form to login? Can Forms Authentication be configured to seamlessly use AD groups and only show a login page when 'denied'?
Cheers
After trying about a million different solutions that all basically led back to the problem of..
It's a pain to check if a user is authenticated before the 401 error is sent - as there is an initial 401 sent to the browser which then prompts for it for authentication..
I came up with a quick and dirty solution, as the project is small and not worth investing much more in.
I placed a very simple check in the page_load event like so, that checks for username if it isn't a postback (first load), and redirects if the static user list isn't found. Far far far from prfect, but it'll do.
if (!Page.IsPostBack)
{
var user = Request.LogonUserIdentity.Name.ToLower().ToString();
if (user != "domain\\user")
{
Response.Redirect("/path/to/redirect/to.html");
}
}
Related
Today, our B2B web application times out user sessions after 6 hours of inactivity. If a user's session times out, the user is redirected to the login page, and then redirected back to the original destination after login (via a "returnURL" querystring parameter sent to the login page).
This works great for regular HTTP GET requests. But what if a user is in the middle of a long data-entry operation and then goes home for the night? If the user tries to submit the form the next morning, their changes are lost.
Instead, I'd like to enable a similar workflow for forms like we currently have for GET requests: the user clicks "save", the user is forced to re-authenticate, and (if login succeeds) then the form would be submitted. Another alternative would be to force a re-login, but instead of submitting the form, simply drop the user on the original page so that the user could try again to save changes.
All the data we need to submit is on the client-- it's not like we're storing data in the session that would have been lost.
Is there an accepted pattern to handle this case? Should I use a window.open popup window and close it after successful login? Use a jquery dialog overlaid on the page? Something else?
I know that login UI is often treated specially by web apps to reduce cross-site scripting risk and for other security-related reasons, so wasn't sure if there was a well-known best practice for this use-case.
One way to handle this would be to periodically save drafts of the user's work, like StackOverflow does. For cost reasons that's not practical in our case-- for now we simply want to make saving-changes workflows resilient to session expiration.
We're using ASP.NET MVC on the back-end if it matters, and jQuery on the front end, but my question is really more about security and programming best practices that I'd expect to be platform-neutral.
It would depend on the amount of data being collected, but a possible solution could be to save the page state to the browser's local storage using either "localStorage" or "sessionStorage". "localStorage" and "sessionStorage" are properties of the web browser that are exposed in Javascript and are supported in most modern browsers (Chrome, Safari, Firefox, IE 9+). "localStorage" holds data indefinitely while "sessionStorage" holds data until the browser or current tab is closed.
It may be possible to store everything needed about the page, redirect the user to log in, and then reload the page using the stored data.
Before redirecting to login:
if (window.sessionStorage) {
window.sessionStorage.setItem("firstName", $("#firstNameField").text());
window.sessionStorage.setItem("lastName", $("#lastNameField").text());
}
After retunring from login:
if (window.sessionStorage) {
$("#firstName").text(sessionStorage.getItem("firstName"));
$("#lastName").text(sessionStorage.getItem("lastName"));
}
I am currently using the Facebook Javascript SDK and the Facebook C# SDK (soley for retrieving user graph objects).
Everything so far is going great except for the following scenario:
User logs into Facebook
User opens a new browser window and visits my
site
Using the Javascript SDK, I can use the FB.getLoginStatus method to determine if they are connected or not (which they are in this scenario as I have previously authorized my site/app for the facebook login).
However, I need to be able to detect upon the homepage of my site loading for the first time, ideally server-side, if we are in this 'connected' state, and if so, render some different content to screen (logged in vs not logged in).
I can't currently see a server-side method in the Facebook C# SDK that enables me to do the equivalent of FB.getLoginStatus (clientside).
I should point out that any subsequent changes to the users loginstatus is handled via subscribing to the auth.authResponseChange event and all is working fine there, but its the first time page load when the user first hits the site that's the problem.
There isn't a way to do this on the server with any Facebook SDK. You must detect the user's status with the Facebook Javascript SDK. The reason for this is because this information is stored in cookies that are either only readable by facebook.com or that are on you domain, but were set by Facebook and should not be parsed by your app.
You can parse the cookies on your domain if you like, but it isn't recommended because Facebook considers those cookies to be an internal implementation detail and does not guarantee their contents. They could change at any time and break your app.
I need to have 2 separate logins for my asp.net web site. Firstly I need to block access to the site entirely and show an unstyled log-in page (so it doesnt show the layout of the site).
This login is only needed whilst the website is in development.
Secondly, I need another login for a "members area" of the site. This is part of the functional site and will be permanent.
I'm at a loss as how to manage these 2 logins. I had first thought of using Windows authentication to allow preview access to the site and then forms authetication for the members part but according to IIS7 I "cant run Challenge based and Log-in redirect based authentication simultaneously".
Any thoughts?
well it is as you've read, you can only set it to either windows or forms auth in a web app, in your case I would've chosen forms auth since it allows you to do pretty much all you'll ever need.
Win auth in my opinion is only a good choice if its gonna be something that is closed and not accessible to anyone else but company, even then I would consider forms auth since I feel I have better control over everything. If you absolutely need both you would need to make them into separate apps.
I implemented something similar from code based on session.
At begin of requests (actually, in basepage.oninit) I am checking if key present in session. If not, I am redirecting user to DeveloperPassword page.
When user enter correct password, he can use other pages as well as windows forms login. For live environment, I use empty password and ignore this check from code.
There is a similar question here:
IIS7: Setup Integrated Windows Authentication like in IIS6
But I think the solution is maybe not what you want.
I assume you just want to restrict people from accessing your development site. If you have a limited number of testes, why not just restrict the IP address? You can do that in IIS7.
Thanks for your suggestions.
Basically I went with using Forms Authentication and a single login page.
When the site is first viewed, the login page is shown with all the styling and header/footer removed.
Once logged in, any subsequent visits to the the login page (to access the member area) show the styling header/footer.
if (!HttpContext.Current.Request.IsAuthenticated)
{
Header1.Visible = false;
Footer1.Visible = false;
Label1.Visible = false;
}
I'm thinking of creating a diagnostics page for an ASP.NET app, which would be mostly intended for admin use to get more information about the application for diagnosing problems.
Examples of the info the page might have :
System.Environment.MachineName (might be useful in web farm scenarios)
System.Environment.Version
Environment.UserName
database name
current user's session ID
Some of the info on this page might be sensitive from a security perspective.
If you've done this sort of page before, what sort of security did you put on access to this page ? .
EDIT :
I should add - occasionally it might be useful to see this page whilst logged in as a specific (i.e. real) end user. e.g. say a problem can only be reproduced when logged in as a particular user. Being able to see the diagnostics page for that user might be useful. e.g. knowing the current session ID might be helpful for debugging.
EDIT 2 :
I'm starting to think that this diagnostics page should in fact be two different pages. One to display stuff which is the same for all users (e.g. database name, CLR version), and another for stuff which can vary by session (e.g. browser info, session ID).
Then you could lock down security more for the first page.
Yes, I've added this sort of page before (and found it useful). The security was pretty simple: the page contained a password form. The server-side code checked this password against a configured value and, if correct, displayed the real content and set a value in the user's session to say that they've been authenticated as a developer, so that they're not prompted again next time.
I suppose there was also a little security by obscurity, since the URL of the page wasn't published anywhere.
I was also careful not to reveal anything really sensitive on the page. For example, it allowed viewing our application config values, but masked out anything with "password" in it - hey, if we really want to see the password we can open a remote desktop session to the server.
There's also a couple of other ways you could do this:
If your web application has user authentication, restrict access to this page by checking that the user is flagged as an administrator or belongs to some kind of admin role.
Use a simple if (Request.IsLocal) ... type check, though the downside of this is that you still have to connect to the server and browse the website locally - which might not always be possible. However, this does still have the benefit of being able to easily view key system settings.
Personally, I've used a combination of both methods where a local request always allows access, and non-local requests require an admin user - eg. if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().
Also, I'm in agreement with Evgeny - be careful not to reveal anything really sensitive on this page (such as application connection strings or passwords).
use forms authentication and setup a user or two with access to that page. that way you can change passwords and revoke access once the site is deployed.
It sounds like you want a robust solution for your error page. I would take a look at open source projects like Elmah (http://code.google.com/p/elmah/) for a good example of a robust error page which includes configurable security. To give you an idea, here is a post on configuring Elmah which takes you through setting up the security. The security I have tested allows me to use my domain credentials to login.
I have code examples from some of my previous work that help me to post form values to a web page (login credentials) and retrieve the text from that page. Now I want to pass in form values (login credentials again) but actually open that web page in a browser given those credentials.
How do I do that? I'm not doing anything nefarious. In our CRM app (home-grown as it is), I want to create a link button that opens our web site's protected products page given the user's credentials (based on the user's login credentials). Normally, I'd copy the user's credentials in our login page which then takes me to the products page. I'm trying to do this now by just clicking a link button.
Any suggestions?
How are you launching the browser? Is this an internal network app? If so, I would recommend using Windows Authentication for your ASP.NET app, and then you don't have to worry about passing credentials. If you can't do that, then you'll probably have to pass the credentials on the querystring generated by your CRM app. Obviously, this is a huge security risk. But the next step would be to perform your internal authentication and then call FormsAuthencation.RedirectFromLoginPage or FormsAuthentication.SetAuthCookie().