Multiple signup forms with UserAccounts for Meteor - meteor

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...

Related

Symfony2 Multiple user Types

Hello I have a technical question on how to implement multiple user types (not using FOS). I'll explain what I'm willing to do, I'd like some feedback on what can be done better or a suggestion on how to do it.
I'll have 4 entities
user
amateur
profesional
organisation
The default one that is implemented right now is user. To get things out of the way I'll user a second user provider for organisation as it will not be related to the previous ones.
I'm wondering how to do the User, Amateur, Profesional accounts.
They share most of the basic fields just have additional information to them. Most of them have the same permissions. Whats the best way to do It?
1) Adding a one to one extra entity to the User Class
I'll add a one to one AmateurInformation and ProInformation to the main User class. And determine the account type by a single accountType field.
2) Extending the Class with a child class?
I don't even know that something like this is possible. Also I'd like to make requests to the Repo that will return all User types.
Again I'm looking for suggestions on what to look into and how I can do this. I want to improve my knowledge while I'm at it :)
In my view two suggested solutions are viable (introducing a type field or using inheritance), really depends on your situation.
I would avoid using multiple independent classes, it will just complicate it.
If the relation to other database entries does not justify, it is not required to create separate classes, you can use the type field and maybe introduce specific roles (see getRoles() in UserInterface) for your different users.
If your user classes will have access to different things (relations to other entities), I would consider using a Single Table Inheritance with doctrine. With this solution you still can use one UserProvider and in code you can check the user object, and also, you can use custom roles to give permissions:
if ($user instanceOf Amateur)

how to implement in wordpress a signup flow that requires a secret activation code

I'm trying to implement a signup flow in wordpress with the additional requirement that a user, to sign up, must use a secret activation code. Such code is valid only once, it's consumed after signup.
Many such codes are available (manually imported in DB is fine).
The use case is to let sign up only users who bought a (paper) book containing the secret activation code. In each book, the code will be different.
Before writing the whole thing manually, is there a plugin with a similar functionality? If not, what is the suggested implementation strategy?
There are a number of modules that already have this functionality, one that I've used before is simply "EasyInvitationCodes". There's also another one called "WP-Invites". If you use "invite" or "invitation" as your search keyword there are a few others available.
For EIC: https://wordpress.org/plugins/baw-invitation-codes/
For WP-Invites: https://wordpress.org/plugins/wp-invites/
Let me know if you've got any questions or if these aren't quite what you're after!

Require extra information in Meteor account sign up

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.

Endpoint design for a data retrieval orientated ASP.NET webapi

I am designing a system that uses asp.net webapi to serve data that is used by a number of jquery grid controls. The grids call back for the data after the page has loaded. I have a User table and a Project table. In between these is a Membership table that stores the many to many relationships.
User
userID
Username
Email
Project
projectID
name
code
Membership
membershipID
projectID
userID
My question is what is best way to describe this data and relationships as a webapi?
I have the following routes
GET: user // gets all users
GET: user/{id} // gets a single user
GET: project
GET: project/{id}
I think one way to do it would be to have:
GET: user/{id}/projects // gets all the projects for a given user
GET: project/{id}/users // gets all the users for a given project
I'm not sure what the configuration of the routes and the controllers should look like for this, or even if this is the correct way to do it.
Modern standard for that is a very simple approach called REST Just read carefully and implement it.
Like Ph0en1x said, REST is the new trend for web services. It looks like you're on the right track already with some of your proposed routes. I've been doing some REST design at my job and here are some things to think about:
Be consistent with your routes. You're already doing that, but watch out for when/if another developer starts writing routes. A user wants consistent routes for using your API.
Keep it simple. A major goal should be discoverability. What I mean is that if I'm a regular user of your system, and I know there are users and projects and maybe another entity called "goal" ... I want to guess at /goal and get a list of goals. That makes a user very happy. The less they have to reference the documentation, the better.
Avoid appending a ton of junk to the query string. We suffer from this currently at my job. Once the API gets some traction, users might want more fine grained control. Be careful not to turn the URL into something messy. Something like /user?sort=asc&limit=5&filter=...&projectid=...
Keep the URL nice and simple. Again I love this in a well design API. I can easily remember something like http://api.twitter.com. Something like http://www.mylongdomainnamethatishardtospell.com/api/v1/api/user_entity/user ... is much harder to remember and is frustrating.
Just because a REST API is on the web doesn't mean it's all that different than a normal method in client side only code. I've read arguments that any method should have no more than 3 parameters. This idea is similar to (3). If you find yourself wanting to expand, consider adding more methods/routes, not more parameters.
I know what I want in a REST API these days and that is intuition, discoverability, simplicity and to avoid having to constantly dig through complex documentation.

Best way to save extra data for user in Drupal 6

I am developing a site that is saving non visible user data upon login (e.g. external ID on another site). We are going to create/save this data as soon as the account is created.
I could see us saving data using
the content profile module (already in use on our side)
the profile module
the data column in the user table
creating our own table
I feel like #1 is probably the most logical place, however creating a node within a module does not seem to be a trivial thing.
#3 feels like a typical way to solve this, but just having a bunch of serialized data in a catchall field does not feel like the best design.
Any suggestions?
IMO, each option has its pro's and con's, and you should be the one to make the final call, given that you are the only one to know what your project is about, what are the critical points of the project, what is the expected typical user pattern, what are the resources available, etc...
If I was totally free to chose, my personal favourites would be option #4, #1 and #5 (wait! #5? Yes: see below!). My guiding principles in making the choice would be:
Keep it clean
Keep it simple
Make it extensible
#1 - The content profile module
This would be a clean solution in that you would make easier for developer to maintain your code, as all the alteration to the user would pass through the same channel, and it would be easier to track down problems or add new functionality.
I do not find it particularly simple as it requires you to interact with the custom API of that module.
As for extensibility that depends from how well the content profile module API is designed. The temptation could be to simply use the tables done by said module for your purpose, bypassing the API's but that exposes you to the possibility that on a critical security update one day in which you are in a hurry the entire system will break down because the schema has changed...
#4 - Creating your own table
This would be a clean solution because you could design your table (and your module to do exactly what you need to), and you could create your own API to be used by other modules. On the other hand you would introduce yet another piece of code altering the registration process, and this might make it more difficult for devs to track problems and expand the system in a consistent way.
This would be very simple to implement code-wise. Also the DB design would benefit though: another thing to consider is that the tables would be very easy to inspect and query. Creating a new handler for views is dead easy in most of the cases: 4 out of 5 you simply use one of the prototype objects shipping with views.
This would be extremely easy to extend, of course. Once you created the module for one field, you could manage as many as you want by mostly copy/pasting the code for one field to another (or to inherit from the same ancestor if you go OOP).
I understand you are already knowledgeable about drupal, but if you need a pointer on how to do that, I gave some direction in this other answer.
#5 - Creating your own table and porting already existing fields there
That would essentailly be #4 minus the drawback of scattering functionality across various modules... Of course if you are already managing 200 fields the other way this is not a viable option, but if you are early into your design, you could consider this.
In my experience nearly every project that requires system integration (meaning: synchronising data for the same user in multiple systems) has custom needs for user registration, and I found this solution the one that suits my need best for two reasons:
I found I reuse a lot of the custom code I wrote from project to project.
It's the most flexible way to integrate data with the other system (in some case I even split data for the user in two custom tables managed by the same module: one that contains custom fields used by drupal only and one that contains the "non visible fields", as you call them. I find this very handy in a lot of scenarios, as it makes very easy to inspect and manipulate the data of the two systems separately.
HTH!
If you're already using the Content Profile module, then I'd really suggest continuing to use it and attach the field to it. You're saving the data when the account is created, and creating a node for the user at the same time isn't that hard. Really.
$node = new stdClass();
$node->title = $user->name; // what I'd use, or you can have node auto title handle the title for you. Up to you!
$node->field_hidden_field[0]['value'] = '$*#$f82hff';
$node->uid = $user->uid;
node_save($node);
Bob's your uncle!
I would go for option 3. Eventually even other modules will store the data in the database against a user. So you could directly save it yourself probably in a more efficient way than those modules.
Of course depending on the size of the data, you can take a call whether to add a new column in the users table or to create a new table for your data with the user's id as the foreign key.

Resources