I am using C# Razor in order to make a social network. There are wepages that contain sensible data and I don't want someone to go to that url and see it. Not even by going to the Inspect Element and open it through there. So is there a way to warn the user that "This web page is not allowed"?
You have to implement authentication and authorization in order to control who can actually access any given route in an mvc application. I can only recommend that you start by reading the official site www.asp.net/mvc/overview/security about authorization and authentication.
With the proper authentication/authorization the server will simply not send any data, or you could redirect to a specific "not allowed page"
I agree with Louis, you should get this book here which helped me a ton. http://www.apress.com/9781430257523
The literal answer you are looking for concerns the use of authorization attributes you place above controller actions or controllers themselves. So an action might look like this
[Authorize]
public ActionResult UserAccount(Guid id){...}
By setting up authentication using ASP.Net Identity you will be able to automatically redirect visitors who are not logged in to another page etc.
Also if you need to make sure that the current logged in user is not going to (for example) another user's personal page (account settings?) you would do a simple check on the server side to prevent this. Something like so (Pseudo code)
if(User.Identity.GetUserId() != account.OwningUserId)
return RedirectToAction("404", "Shared");
Related
I have configured emberjs to use IDS4 before but I use it with simple auth and torii - however - on the site I am building now I do not want a pop up for auth and i also want to allow users to register through my site.
WRT the 1st issue - no popup - I can see that I can use
mgr.signinRedirect();
As shown in https://github.com/IdentityServer/IdentityServer4.Samples/blob/release/Quickstarts/7_JavaScriptClient/src/JavaScriptClient/wwwroot/app.js#L41
But that would mean hosting the login page as part of IDS and that means maintaining the CSS, markup and JS to make it look like it's a part of the main site - this I do not want to have to do.
What is the way to handle this?
The EmberJs site has a .NET webapi backing it - is there a way to POST the username / pass to the API and have the API proxy the auth?
WRT the 2nd issue - registration - I guess the question is - is there a way to do the same as above? send the new user details to the API and have that issue the request to IDS to create the user?
[UPDATE]
From looking around the quickstarts it seems there is no way to allow a JS client to register and authenticate without using a popup or a redirect to the views hosted on IDS... am i right?
This is crazy...
I am very new to MVC . I have a address of view in my Addressbar as
http://localhost:3436/User/View1 When I edit the word View1 and add View2(Which is another view ) i am redirected to it..
I also noticed that such behaviour is working in Stack Overflow
How can I disable this behaviour in my MVC 2 ?
It is not possible to completely disallow GET requests manually formulated in the address bar of a browser. Are you restricting access to the view based on user privileges? If so, you should use the AuthorizeAttribute to prevent certain actions based on user authentication and authorization. If you are trying to prevent the user from browsing manually rather than being restricted to links you provide, then you have limited options such as obfuscating the url, checking for empty referral url, requiring a POST token, etc. This leads to poor usability and is not recommended. Simple checks like referral URL are easily spoofed anyway.
I'm using the Thinktecture.IdentityServer.v2 app to perform SSO for a couple of internal apps but would like to customize the login page for each application to have a smoother user experience. I can't seem to find a way to do that.
Can the login page be customized depending on the source application from where the client is comming?
"I can't seem to find a way to do that." - How hard have you tried? ;)
The RP has the extra data fields - so you can hang like a CSS name off the RP in the registration database. Further you can get to that RP data from the signin page - quoting the comment in AccountController:
// you can call AuthenticationHelper.GetRelyingPartyDetailsFromReturnUrl to get more information about the requested relying party
btw - IdentityServer's github repo has an issue tracker - you should use that for questions.
You can always have the RP pass a custom query string param and customize off of that. But you're outside the bounds of WS-Federation at that point. Plus, you must think about the nature of SSO -- the user is really signing into the IdP, not the app. So changing the IdP to look like the app is somewhat disingenuous.
I have solved this by customizing the SignIn.cshtml to adjust the style to what I need. Additionally, I have server side code in the top of SignIn.cshtml that does some string matching on the ReturnUrl (Request.QueryString["ReturnUrl"]). Then I show a different logo and header text based on some values I know to be unique for the different RP urls.
When upgrading to a new version of the ThinkTecture MVC, it will be a small job to update only this file to your specifics (just remember to have a copy of your modified SignIn.cshtml before you upgrade).
i have an application and a user must log-in before he/she can access pages. now once the user logs in i keep the user details in a session variable (say Session["CurrentUser"]).
now if a user tries to jump to a page directly i will check if the Session["CurrentUser"] has a value or not...if not then the user will be directed to the login page...
my problem is that i have done this or rather say written this "Checking Code" on almost all the pages.
what i want is this code to stay on a particular location and i will just access that method all the time on all the pages...now where should i write this method ??
thank you.
You could create a class that inherits from System.Web.UI.Page and then have all your individual page classes inherit from that. Have you looked at the built in ASP.net forms authentication techniques?
You should take a look at ASP.NET Authentication. This will allow you to secure a section of your website, or individual pages via the web.config file and uses a cookie to handle authentication instead of you checking a session variable.
You could put it in a base class which extends Page, then have all your pages codebehinds extend this.
A better solution would be to use the
Application_AuthenticateRequest
pseudo event in the Global.asax. You really shouldn't be using the session either, have you looked at Forms Authentication?
In an aspx C#.NET page (I am running framework v3.5), I need to know where the user came from since they cannot view pages without logging in. If I have page A (the page the user wants to view) redirect to page B (the login page), the Request.UrlReferrer object is null.
Background: If a user isn't logged in, I redirect to the Login page (B in this scenario). After login, I would like to return them to the page they were requesting before they were forced to log in.
UPDATE:
A nice quick solution seems to be:
//if user not logged in
Response.Redirect("..MyLoginPage.aspx?returnUrl=" + Request.ServerVariables["SCRIPT_NAME"]);
Then, just look at QueryString on login page you forced them to and put the user where they were after successful login.
UrlReferrer is based off the HTTP_REFERER header that a browser should send. But, as with all things left up to the client, it's variable.
I know some "security" suites (like Norton's Internet Security) will strip that header, in the belief that it aids tracking user behavior. Also, I'm sure there's some Firefox extensions to do the same thing.
Bottom line is that you shouldn't trust it. Just append the url to the GET string and redirect based off that.
UPDATE: As mentioned in the comments, it is probably a good idea to restrict the redirect from the GET parameter to only work for domain-less relative links, refuse directory patterns (../), etc. So still sanity check the redirect; if you follow the standard "don't use any user-supplied input blindly" rule you should be safe.
If you use the standard Membership provider, and set the Authorization for the directory/page, the code will automatically set a query parameter of ReturnUrl and redirect after a successfull login.If you don't want to use the Membership provider pattern, I would suggest manually doing the query string parameter thing as well. HTTP referrers are not very reliable.
The problem could be related on how you redirect the user to some other page. Anyways, the referer url is nothing you should take as absolute rule - a client can fake it easily.
What you're looking for is best done with a query string variable (e.g. returnURL or originURL). Referrer is best used for data mining operations as it's very unreliable.
See the way ASP.Net does redirection with logins for an example.