I'm working a Meteor app which uses accounts-password, and linking to other services wouldn't make sense. However, I would like to be able to require additional information, specifically their real name. From reading the docs, the data should be stored in user.profile. How can I require information at signup? My best guess is extend accounts-password and accounts-ui, but it seems like a common enough problem, so there might be a better way.
There isn't a great way to do this currently that I know of. Extending Accounts-UI is a nightmare. I strongly suggest just doing it yourself, it's not very hard. Meteor provides the Accounts.createUser function you could use for this, as well as other related simple to use functions in the Passwords documentation. The createUser function actually accepts an options object, which can specifically contain a profile object for the additional information you would like to add. Set up a template yourself with all the html form fields you want, make a submit event hook for it that calls either Accounts.createUser or a Meteor function that does some other stuff first. This method gives you styling flexibility also, which is a pain in the neck with the Accounts-UI package.
Use Accounts.createUser() and something like:
Accounts.validateNewUser( function( user ) {
return !!user.profile.name;
});
You'll probably want to make your own form for this - the accounts-ui package is great for prototyping, but when you need custom requirements like this it's easier to roll your own. See BenjaminRH's answer for the basics of creating a custom login form.
Related
I'm using the http://useraccounts.meteor.com/ package for user auth templates and functionality. However, I have two different user types that require different signup forms. I'm using:
AccountsTemplates.addField({ });
to customize Form #1 and was hoping to use another call like this for Form #2 but when I do so, I get:
Error: AccountsTemplates.addField should strictly be called before AccountsTemplates.init!
I could of course make a custom form for one of them but I would like to stick to using the package as it keeps things tidier.
How could I create two separate instances of the signup form??
#PhilippSpo is right, at the moment there is no easy solution to this use case.
There's a bit of a discussion here proposing a workaround, even though it's not a suggested practice.
Actaully you could make it work as long as you don't want to have different required fileds in the two forms, but there's no way to get it done in case you'd like to have different required fields for the different user types.
The problem arises because one of the selling point of useraccounts packages is the strong server-side validation of the new user profile: letting users sign up with different lists of required fields might open doors to trick the sign up process...
I am pretty new to meteor and I am trying to make my first app which should have a profile page, later also with picture upload depending on user group.
As I understand I do not need a extra collection and subscription.
I am using useraccounts:bootstrap package with accounts-password. I added some custom fields to the profile (firstName, lastName, country).
Now I want to create a update or edit page. I could not find any resources which could been helpful.
Do I need to write all the logic for example testing the email address by my self? Or is this included by the package.
Or is it better to create a new collection for users with meteor-collection2?
Thanks
Witali
Collection2 will just attach its schema to the original user collection (if you proceed like suggested in collection2 readme).
As far as I know, I'm afraid that you will have to create some publications. Since editing user should be considered as "must-be secure", I would advise you to take a look at the existing packages. I'm quite a newbie to so I didn't look into the code of alanning roles package (which is, I've been told, excellent).
I used https://github.com/perak/user-roles. I think the code is good and clear.
The same guy, perak, made a meteor code generator which is still a work in progress, but looks very promising to me. Get one of his examples with user account and look at the client folder. You will have, when considering his user-roles package, all the code to do what you want.
ps: for email testing, look at his files in the client/lib folder but it is just a regex
I am struggling with a problem. I've got a sitetree, in which I - obviously - have pages. These pages are of a type that has a many-to-many relationship to a dataobject. Now I would like to achieve something like this:
/Page/DataObject-slug
So, when the system detects that there is an additional "layer" in the url, it should pass that to a predefined function within the Page controller.
Can I use $allowed_actions for that, or would it interfere with the default routings? Also it should be able to use a wildcard, as I don't know the DataObject-slug in advance. If that's not possible, are there any other known ways to achieve this or something similar?
As an alternative, I probably could do something like /Page/SomeAction/DataObject, but that would be really ugly, and probably not acceptable for the customer.
Another option would of course be using controllers as pages, but that would remove the possibility to nest Pages easily for the user, and create a structure like /ParentPage/Page/DataObject-slug.
I am using SS 3.1.6
I successfully used https://github.com/NightJar/ssrigging-slug for this. It shouldn't matter if your relation is a has_many or many_many, you can access the items in your controller with $this->ManyManyRelationName()
It utilizes $url_handlers for this job.
If you have any problems installing it please provide a paste of your code.
Will someone please tell me how to create a user without using membership.createuser() and create user wizard in asp.net? I need to perform an additional insert on an existing table during CreateUser().
Here are two ways to go:
Implement your own custom membership provider. This is easier than you think and pretty straight forward. There are plenty of articles around.
or
To save you some time... implement your own custom membership provider and inherit from the SqlMembershipProvider class. In the subclass you will mostly just "forward" the calls to the base class except for in the CreateUser method. In this case you can let the base class do most of the work and then perform your custom insert. However, since it does need to be in one transaction (per your comment above) then things might be a little hairy... and you would possibly have to reimplement the CreateUser method in your subclass.
http://msdn.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.aspx
Note: I am on a bus right now via Wifi, but I am almost tempted to write this for you if you include the emp_details schema for me. Are you using straight ADO.NET or something else?
My problem is quite simple - I think. I'm doing an ASP.NET MVC project. It's a project that requires the user to be logged in at all time. I probably need the current user's information in the MasterPage, like so; "Howdy, Mark - you're logged in!".
But what if I need the same information in the view? Or some validation in my servicelayer?
So how to make sure this information is available when I need it, and where I need it?
How much user information do you need? You can always access the Thread.Current.Principal and get the user's name - and possibly use that to look up more info on the user in a database.
Or if you really really really need some piece of information at all times, you could implement your own custom principal deriving from IPrincipal (this is really not a big deal!), and add those bits of information there, and when the user logs in, create an instance of the MyCustomPrincipal and attach that to the current thread. Then it'll be available anywhere, everywhere, anytime.
Marc
I've had exactly the same issue, and have yet to find a satisfactory answer. All the options we've explored have had various issues. In the specific example you mention, you could obviously store that data in the session, as that would work for that example. There may be other scenarios, that we've had, where that may not work, but simple user info like that would be fine in the session.
We've just setup a BaseController that handles making sure that info is always set and correct for each view. Depending on how you're handling authentication, etc, you will have some user data available in HttpContext.User.Identity.Name at all times. Which can also be referenced.
Build a hierarchy of your models and put the shared information in the base model. This way it will be available to any view or partial view.
Of course it has to be retrieved on each request since web applications are not persistent.
You should store this in Session and retrieve it into your controllers via a custom ModelBinder.
Not sure if I get what you want to ask, but if you are looking for things like authentication and role-based authorization, actually ASP.net is providing a great framework to work on/start with.
This article (with also 2nd part) is something I recently discovered and read about which is really good start with the provider-pattern which help to understand the underlying authentication framework of ASP.net. Be sure to read about the membershipProvider class and the RoleProvider class in msdn also, they together make a great framework on most basic role-base authentication to work with (if you are comfortable with the function they provided, you even don't need to code data-access part, all are provided in the default implementation!)
PS: Check out Context.Users property too! It stores the current authenticated user information.
HttpContext.Current.Users.Identity returns the current user's information. Though I am not sure whether it gets passed implicitly when you make a webservice call.