I've inherited a DotNetNuke site that was built and managed by someone who thought storing user passwords as plain text was a good idea because he could easily look up a password and tell the user what it is if they forgot it and to log in as them if they had an issue. After recovering from my heart attack at discovering this and getting my mind to navigate away from the idea of how stupid that is, I need to fix it.
I know to change the web.config settings to use the correct password configuration, but was hoping someone else that's had to do this with a DotNetNuke site might provide some guidance on the best way to approach this. Should I just use standard .NET code and write an app to cycle through them and change them or do I need to use the DotNetNuke user objects? Any article links or sample code would be really helpful. I've found posts about doing this generally but not in the context of a DotNetNuke site and am unsure if there's any special considerations I need to take into account.
Sadly there isn't any real documentation that I'm aware of that would handle this. My recommendation would be to make the web.config change to hashed. After doing this user resets will start using the new format.
You could then write a simple module that grabs all users with plan text and resets their password using the ChangePassword API call from the UserController API. It isn't elegant but would get the job done.
Related
Can anyone tell me what the benefits and disadvantages are of the ASP.net login module and building your own login? Or links to where I can get more information.
Thank you!
Further to what talljoe said it is less work and also standardised which will help anyone else that comes in need to make changes.
Unless you need some specific function that the control doesn't have, there's no real need to write your own.
I have not found the same as or related to my question above.
If it is already asked, please let me know, I will delete mine.
I am learning asp.net mvc 2.
After downloading the rendered page, the visitors have a chance to manipulate the html contents ILLEGALLY and submit it back to the server. In MVC, how can I avoid this issue?
You cannot prevent anything on the user side. Therefore you must ensure that the server reacts correctly to manipulated input.
Note that the automatic model binding is tricky: both over- and under-posting can cause trouble.
This is an excellent post on that topic: http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html
Take all the efforts you can to validate the user input at the server. MVC offers the AntiForgeryToken which helps verify that the page being posted back is the correct page but as with any client-side verification, it's not foolproof.
You can't do anything about this.
Use the mantra "never trust anything from your users" and validate everything on server side.
I am currently trying to figure out how to best go about implementing an administration side for my application.
I have a user site, where users can log in, customize their profile, submit information etc.
I would like administration users to be able to log in and be able to choose from a list of users. From there, the administrator can submit information for the user just like the user can.
Website Start Page > RogerRabbit > Submit Information
Website Start Page > BillyBob > Customize Profile
So my question is:
How should my pages be laid out?
How should the Web.sitemap file look? Is there a nice way of creating a sitemap (maybe in memory?)
Would this method have to use session variables?
Any suggestions, or tips would be great.
I can't answer your sitemap question but I have implemented a solution like this on one of our systems where I can see exactly what the end user is seeing by impersonating them. I did this mainly for troubleshooting purposes so that when they report a problem to me (such as something missing from their view), I can go in as them and see exactly what they are talking about.
The way I did this, which is admittedly a little crude, was to have an impersonation table in my database which contains the logon name of the user who is doing the impersonating and the logon of the user they wish to impersonate.
I added some override code so that when the user first goes to the page (it uses Windows authentication), it will check to see if that user has an impersonation set in the table and then place this user id in an object in the session state. If there was no impersonation, it would place the actual user id in this same object.
To prevent me from doing things to the user's data as them, there are two properties in this object, one for logon_name, which is what is used by the system for content-customization, and another called NameForLog, which is used when logging any actions. All actions I make will be logged as me.
All areas on the site that display user-customized content look at this session object, so they will always use the impersonated ID and therefore always show me what the user is seeing. Beyond the first page and the logging code, it doesn't even know that it is me it is dealing with.
It isn't the cleanest solution, but it has worked well for me.
I dunno mike... that's a broad set of questions there. Kinda like asking "how to I build a web site in asp.net".
It sounds very much like you need to invest in an introductory "how-to asp.net book" that covers these topic areas. The good news is that just about every beginner to intermediate asp.net book ever written probably hits most of these topic areas.
would like administration users to be able to log in and be able to choose from a list of users. From there, the administrator can submit information for the user just like the user can.
This is a kind of impersonation... and is a lot harder than it sounds. But how you do this depends on how your application authenticates users, authorizes users, and manages roles... which is a whole sub-specialty within asp.net (with it's own dedicated books actually).
1) How should my pages be laid out?
Carefully?
2) How should the Web.sitemap file look? Is there a nice way of creating a sitemap (maybe in memory?)
This is covered on MSDN quite thouroughly. Yes, you can create your sitemaps in memory. I've created sitemaps from data stored in a SQL DB a few times in the past, but I'd have no idea where to even start to explain it. You have to understand the base classes and interfaces used by sitemaps and then make a custom sitemap provider adapted to working with your data and rules for the site's structure.
3) Would this method have to use session variables?
Probably. Most sites with an awareness of "logged in user" need sessions. Not universally true, but nearly so.
I have a requirement to check that all the hyperlinks still work on a password protected, private website. What's the best way of doing this?
The site is mix of HTML and ASP.NET Webforms.
EDIT: Sorry - I don't think this question was clear.
I need something like this:
http://validator.w3.org/checklink
But for a site hidden behind a user/pass form. I don't mind doing something programmatically or purchasing something if it's reasonable.
You should seriously look at the unix command line tools to do this. Esp wget
take a look at the --spider option in combination with the --user and --password options...
Also take a look at curl or libcurl+php
There are two things that are not terrible clear about your question.
First, what sort of user/password are required. These can be POST values or they can be the username and password from the http protocol. Which do you want? There are several ways to provide a username and password to a website, and whatever solution you use has to work with your website. That means that you have to have a very accurate understanding of which method you are using. Just the fact that it has a username and password is not nearly enough information.
Second it is unclear what you mean by "links still work" do you mean internal links that will or will not work based on the proper functioning of your application, or do you mean links to public Internet sites that happen to be on a password protected site?
I am assuming the later with this answer. But if you meant the former then you should look into one of several web application test suites that have recently come available.
HTH,
FT
Rel Software's Web Link Validator works quite happily with Forms Auth based sites - we've been using it on client sites for some time now.
The main things to watch out for are:
Send the link checker to your Login Page first.
Ensure you tell it to ignore all Logout URLs (so it doesn't inadvertently log itself out).
I enjoy using SimpleTest for testing my own websites, but there's no built-in link checker.You could use it to navigate the login and fetch the page body. You'd then parse the content using regular expressions to find all links, and use SimpleTest again to verify those links (and even crawl them to verify recursively).
Of course, using cURL (or libcurl with your language of choice) gets you pretty close, too.
You just need to authenticate the WebRequests ...
Where are you stuck?
-- Edit
Well, it depends on what you mean by 'password protected'. How do is the login scheme implemented?
You can do this using Apache httpclient has the features
i noticed that a forms authentication element has an option child element called Credentials.
MSDN Online explains what it is, here.
That said, i don't understand what it would be used for? So i can add in a username and password (either clear/md5/sha1) to the config file.. but how/when is it used?
Is that an example of hard-coding in a username/password to be used with forms auth, instead of having a database? If so, is there any code behind? What happens if you also have a database with users/passwords?
cheers :)
You're exactly right... hard-coded username/passwords. That's it in a nutshell. Only time I've actually used it is on a project where we wanted to work on some code that required authentication, but didn't have the real mechanism wired in. It's just a placeholder for real authentication so far as I'm concerned.
MSDN seems to agree, given the warning note at the top of the docs you link to. You can use it side-by-side with a DB, but why bother?