I was wondering if it is possible to make it so the editors within sitecore can set it so you require a username/login to only one specific page.
www.yourwebsite.com - No password required
www.yourwebsite.com/internalstuff - password required and set within CMS by the editors.
This is explained extensively in the Security Administrator's Cookbook that is supplied by Sitecore.
This is what you need to do, in a few short steps:
Create a user group with the User Manager (on the Extranet domain, that's how it's called by default, could be different in your installation)
Add users to the group
Go to the Security Editor, select the item(s) you want to protect, and disallow Read rights for the Anonymous user (this makes it impossible for not-loggedin users to view it)
Enable Read rights on your item(s) for your new user group
Make sure to read the cookbook so you know how to use security inheritance properly. That will save you a lot of time in the future.
Actually it's possible with no coding if you have Web forms for Marketers installed. It's not an enterprise ready login with e-mail activation etc. but it works. First, you should of course set up access rights and roles as mentioned in this answer by Ruud plus you need WFFM ready with forms styled and a placeholder configured to accept forms.
Go to WFFM and create a registration form (username as single-line text field, password as password-confirmation field)
as save action add "Create User" (configure correct domain/role there) (you could also add a "User Login with Password action and log the user in directly after registration)
add the registration form to a public page
create a login form (username as single-line text field, password as password field); again map the data to the username, password and domain set up for your extranet)
add the login form to a public page
enjoy :)
Note: this requires you to have write access to the asp.net user tables (by default set up in the core database). Make sure your security requirements are compliant with that. And as already mentioned this will not give you a basic e-mail validation up on registration.
Related
I want my website to be seen by anonymous users. and i don't want it to have a login /register user part.
i just need one user as administrator and its username and password is chosen manually.
what is the best practice to implement this login part (website has only one user for ever).
my question is how to implement this one user login part, where store username and password and does it need a table in database?
For me - if you're having such a simple system, then merely storing the username / pwd in the web.config is fine.
I'd create a helper class to wrap up talking to the config file (ConfigurationManager.AppSettings on MSDN) and use and evaluate a simple "logon" action.
No table needed.
Finally - make sure you add the AuthoriseAttribute to your controller that will be doing the admin actions...
HTH
Simplest way - just delete the controller and the view responsible for registering new users, change the routing to the login page and you're set.
Could anyone please provide me with guidance on whether it's possible to use aspNetActiveDirectoryProvider for Authentication and aspsqlProfile Provider to store user specific details?
I'm not quiet getting my head around on how do I get userID that's required for aspnet_profile table if I were to switch to Active Direcory.
Also, is it possible to change password from aspnet admin page if active directory is used?
Regards,
Changing password is possible with AD provider: see ActiveDirectoryMembershipProvider.ChangePassword method.
ASP.NET profile generally associates profile with user name. Typically, user name value will be same as the user identity value used by authentication system. So in active directory case, it would be user's domain qualified login-name (in form of <domain>/<login>) - see this link for more info: http://msdn.microsoft.com/en-us/library/ewfkf772.aspx
You may also create a custom profile provider if you need more control at database schema side - sample is already available from microsoft and you can use that as base, check these links:
http://msdn.microsoft.com/en-us/magazine/cc163457.aspx
http://www.asp.net/downloads/sandbox/table-profile-provider-samples
I have a very basic understanding of ASP.NET and I am trying to do the following. I have a home page that is set-up to be a login page. If you could just picture a username and password box that is the extent of that home page. Once the user is logged in they will go to a different page let's say the account page. However, when the user clicks the logo at the top left hand it takes them to the home page again but it shows the username and password boxes again ready to be filled.
The user status at the top of my page still shows that the user is logged in. What I am trying to do is add a piece of code that will change the link of the logo to display the account page once they are logged in and not the login page.
I don't know if this can be done through the web.config file since I read a different article that has something similar to this or if this code can be put directly next to the code where my logo link (default.aspx) sits.
Many thanks in advance!
Research the Membership Provider.
It's an industry standard in ASP.NET session management. It will manage all of your pages and allow you to customize pages, menus, etc. based on roles and permissions. Don't reinvent the wheel if you have the oppertunity to use it.
Straight from MSDN:
ASP.NET membership supports facilities
for:
Creating new users and passwords.
Storing membership information (user
names, passwords, and supporting data)
in Microsoft SQL Server, Active
Directory, or an alternative data
store.
Authenticating users who visit your
site. You can authenticate users
programmatically, or you can use the
ASP.NET login controls to create a
complete authentication system that
requires little or no code.
Managing passwords, which includes
creating, changing, and resetting them
. Depending on membership options you
choose, the membership system can also
provide an automated password-reset
system that takes a user-supplied
question and response.
Exposing a unique identification for
authenticated users that you can use
in your own applications and that also
integrates with the ASP.NET
personalization and role-management
(authorization) systems.
Specifying a custom membership
provider, which allows you to
substitute your own code to manage
membership and maintain membership
data in a custom data store
I'm try to use drupal open id module. When i used to login using any provider id(yahoo,google,facebook..) it goes to registration page of my site. My question is how to populate details of the user to my form without additional burden to the user ?. For ex name,email-id etc. Is there any module associated with it ?
I haven't tried this, but this module sounds like it does what you want:
http://drupalmodules.com/module/openid-autoregistration
"Module allows automatic registration of (successfully logged in) OpenID users, even in case OpenID provider didn't supply data necessary for Drupal user registration (valid username and email)".
I am writing a web app for a client. Users will have a one-time key that they will use to initially identify themselves to the app. Once the app verifies that the key is valid it will take them to a page where they can create a normal account to use for all subsequent logins. The create-account page should only be accessible after entering the key and shouldn't be accessible otherwise. I.e, it shouldn't be accessible to users logged in with a normal account.
This is asp.net 3.0 using a custom membership provider.
My plan is to create a temporary account based on the key and authenticate the user with that account. This allows them access to the create-user page (which is protected with a location tag ) where they can create the formal account. I then authenticate them with their new account and delete the temporary account.
The flow is: the user goes to a page where they enter the key. If the key is valid I create the temporary account, call FormsAuthentication.SetAuthCookie, and redirect to the create-account page. This all works, although it seems a little complicated.
The problem is that the create-user page is available to any authenticated user; I only want it available during the time between entering the key and creating the formal account. So I thought I'd create a special role for the temporary account and make the create-user page accessible only to that role and none other. I created my own Principal object with a special role and tried setting it when I authenticate the temporary account but I can't get that to work.
I'm really hoping I don't have to write a custom role provider just to do this.
How can I make this work? There's gotta be a simpler way!
Why not simply create the real account when they enter the key. Assign it some random name and then let them change the name and other details. Then you don't need the create user page, just the enter key page and an account details editing page. If you're concerned about getting the account details filled in, you could set it up (perhaps via code on a MasterPage) so that incomplete accounts always get redirected to the edit details page until the details are entered.
Or, you could have them enter the required details in addition to the key code on the enter key page and simply use those details when creating the account.
My advice would be to avoid the use of temporary accounts when validating the user. Instead, generate your own logic for validating the sign-up key. Then, at the head of the page, you can check whether the user is an authenticated user (SetAuthCookie has been called) and jump to a different page if this is true.
You may even be able to change the page access to forbid this page to authenticated users (I know you can disable accounts for unauthenticated users but I'm not sure if you can go the other direction).
The key, though, is to avoid relying on the membership provider when, in fact, the user is not yet a member!
Assign an "incomplete" role when authenticating against the temporary token, then restrict access to only that role... when the account is created, send them to a re-login page (terminating the authentication token). This will simplify your security model.