I'm absolutely new of Symfony, and I'm trying to implement a registration form that works only with invitation
but that can redirect two different forms for two different roles.
In practice if I send an invitation for an USER_TYPE1 role the client can only register like USER_TYPE1, if I send an invitation for an USER_TYPE2 the client can only register like USER_TYPE2 (and, of course, assigns the corrispondent role).
Is it possible?
thank you in advance for your help
UPDATE:
I want two different form because one user will be allowed to update file, but will also have to set his position and other important settings. The second user will only allow to download the files uploaded by the first kind of user, and his profile needs completely different information.
I do not have enough reputation to ask for details, but one thing that is not clear in your question is: why do you need 2 different forms? In your question, you mention 2 different roles, but why do you need 2 different forms? If you really need 2 different forms, then you should first:
- create a new form type
- create a new view (twig)
Like Boris suggested, I would keep some kind of token for every invitation sent, and associate an email address, and a role to it. Then modify your registration route so you can pass a token in there, like this:
register:
pattern: /signup/{token}
defaults: { _controller: MyBundle:Registration:signup }
In the registration action of your controller, you created the correct form type and display the appropriate twig, depending on the ROLE associated to the token you just got. And when handling a POST, you check the Token again to see if it matches the email address, and assign the proper ROLE when creating the User.
public function signupAction($token) {
// 1. Get the Token entity matching the $token variable
// 2. Create the correct form type
// 3. Display the correct twig for GET, assign correct ROLE to new User for POST
}
But you can't use FOSUserBundle as-is. You will have to overwrite the registration process. You can read the FOSUserBundle documentation about that.
What's certain is that, for every invitation you send, you should keep a token with a matching email address and ROLE (the role you want to give to that person).
Related
I've extended the User model in my loopback application, and added phone number as a login method, I use the username field to do this, the only deal is that on login I get the 'email not verified' error, I have my own phoneNumberVerified field, and have overwritten the confirm method to validate the token against the emailVerificationToken and against the phoneNumberVerificationToken and update the corresponding flag, I thought of overwriting the original login method to not allow login only if both emailVerified and phoneNumberVerified fields are false (not just the email) but I don't know how to actually do the login the way loopback does it (I believe it creates an AccessToken or something), and I'm asking for some help on how to do this, thanks XD. I can do the overwriting and validations myself I just need to know how to do the actual login without using the original login method, since I'll be rewriting it.
So I figured out that I actually don't need email or phone number verified validation at all on login (later on the workflow will be required, but that'll be another use case, so it's irrelevant on login to me now XD). So when I was looking on how to overwrite the login method I realized that all the models code it's on the node_modules folder xD
node_modules/loopback/common/models/user.js
And found there in the login method a flag that validates if should check email verified or not, so on my startup script I just put this:
app.models.MyUser.settings.emailVerificationRequired = false;
That stops the email verified validation on login.
And maybe if some of you would like to override the login method I believe copying the whole method from the original user model up there and attaching it to your model and doing some modifications might work xD, it invokes the createAccessToken from the user model (itself) and that's what I believe creates the 'login', what I came to understand is that there is no "session" data, it creates an accesstoken when you successfully login, and as I've been doing just sending the token id to every request 'authenticates' your logged user.
Thanks for reading, have a nice day :)
I'm developing a basic recruitment-type website.
I have an "Apply" CustomForm attached with a contenttype("Job"), but I can't get access fields outside of the CustomForm widget. I'm trying to add the reference number or the url to the email within the workflow. Orchard shows {Content.Fields.Input-Reference} token, but it returns no value when used.
Should I overwrite the handler when the form is created or how can I access fields of other zones?
As far as I understand the question, you don't actually need to add a custom token to your module. Custom Forms module takes care of that for you and adds the tokens for fields itself. You just need to use them in the email module.
Just look for a tokens named like this:
Content.Fields.[FormContentTypeName].[FieldName]
Not that the tasks of adding custom tokens to the system and accessing them inside the workflow are particularly hard, mind you.
I'm working on a web application under Laravel and I'm trying to be as RESTful as I can, but admittedly this is the first time writing this kind of application.
I'm specifically trying to create RESTful URI's for the controllers of my project.
So far I have (in pseudo code)...
URI Goes to... Desc
--- ---------- ----
/ GET
if logged in dashboard GET
else frontpage GET
login GET login GET login form
login POST login POST attempt login
login DELETE login DELETE logout
user GET
if logged in user GET show user control panel
else login GET redirect to the login w/ error
So far so good, but how should I go about creating a new user?
I had a couple of ideas, for example:
URI Goes to... Desc
--- ---------- ----
user/create GET register GET show the create user form
user/create POST register POST attempt to create a new user
So we use a register controller here, but we hide it behind the user URI.
Advantage here is that we stick to HTTP actions (just GET and POST), and we create a nice readable URI.
Disadvantage is that our URI does not accurately represent our controller.
URI Goes to... Desc
--- ---------- ----
register GET register GET show the create user form
register POST register POST attempt to create a new user
In this case we have A. used HTTP controls, B. created a URI that is a representation of our controller, and C. created a nice readable URI, but unfortunately our URI isn't really representational of the data. In no way is this register controller representative of our user.
Which is more appropriate? Why? Is there a better way? Thanks!
In those cases I would create a Route::resource for users, like so:
Route::resource('user', 'UsersController');
and to optimize user readability add:
Route::get('/signup', 'UsersController#create');
For logins I would create a Route::resource for sessions, like so:
Route::resource('sessions', 'SessionsController');
and to again, optimize user readability add:
Route::get('/login', 'SessionsController#create');
Using resources makes some methods ready for you, but you are not using all of them.
So you might want to reduce that to the ones you use, only. Like so:
Route::resource('sessions', 'SessionsController', ['only' => ['create', 'store', 'destroy']);
Hope this helps you further.
In your case I will go for the user readability. I always prefer to have something like example.com/signup, example.com/register to show the form that handles the creation of the user. As a user, the URL tells me that I'm in the right place, even if the controller that handles this is totally different. The middle URL (where you will post your data) is not important because it will not displayed to your users: you will redirect them to the create form or the success page.
If you were building an API (the intended users are developers) I will go for a POST users, because developers should be familiar with REST principles.
Assume I want to create a very simple todolist RESTful API, where each user owns a list of todos. The user is already authenticated over http BASIC or DIGEST.
At this point I am not sure what the URL scheme should look like.
Would it be:
http://servername/todos/
where my server filters the appropriate todos according to the authentification given to me by the http header.
Or should I include the username in the URI instead:
http://servername/users/username/todos/
On some websites I have even seen that they hand over the user name as a parameter like this:
http://servername/todos?username=babsi
As far as I can tell all three choices are stateless as I always receive the username, but just over different sources. From what I can tell to make sure that the URI is accessed by the proper user I always need to check the http header anyways. So which of the ways would you consider the best URI design in REST or should I do in a different way entirely?
You can use the following:
http://servername/todos/ GET list all todos
http://servername/users/ GET list all users
http://servername/users/{user_id}/ GET list an user
http://servername/users/{user_id}/todos/ GET list all todos for an user
I think the point here is how you want to design the relationships between your resources, if a todo just can exist in the context of an user use a hierarchy like approach as above.
As general rule i usually follow this:
Use path variables to encode hierarchy: /parent/child
Put punctuation characters in path variables to avoid implying hierarchy where
none exists: /parent/child1;child2
Use query variables to imply inputs into an algorithm, for
example: /search?q=jellyfish&start=20
Having the username in the URL depends on what you want to do (if anything at all) when you receive a request where the username in the URL does not match the authentication. If you want to re-authorize the user in this situation then yes - it's OK to have the username in the URL, otherwise it's OK to have it just in your header or other authentication scheme if there is no such need.
One fairly common example of a valid requirement would be if you have to have a main user (or group of such users) that can impersonate other users.
When the user in question is always the user who is holding the authentication token, then use something like "me" in your path.
http://example.com/users/me/<path-to-inner-resource>
Otherwise, user should be treated just like any other resource in your system, in which case the resource identifier for that user becomes a part of the path.
http://example.com/users/<id>/<path-to-inner-resource>
Take a look at Twitter APIs as an example.
https://developer.twitter.com/en/docs/twitter-api/users/follows/quick-start/follows-lookup
I'm using Drupal 6.16: When a user creates an account on my site I have them select a category (ie children, youth, adult, etc). This is done with the select list box using the content_profile module. I have a content type that posts an announcement. In this content type is a check box that says 'email group'. Right now it does nothing, but what I would like for it to do is e-mail all the users that are associated with the group they chose when signing up for their account. If this will require extra code please be specific as I am not a strong php programmer.
Thanks for the help!!
msindle
There might be some module that do it exactly, but I don't think so.
I would have done it using few building blocks:
Retrieve the list of emails using Views - define a view that gives you the addresses according to a given group argument.
Use Rules module that will send an email notification after node is created.
Combine the two (this is the hard part) - insert the values from the view as the recipients for the email. You might be able to do it using PHP inside the Rule definition, plus view execution.
Try to accomplish it, and if you get into troubles, you are welcome to contact me via shushu.i#gmail.com
I would try http://drupal.org/project/subscriptions module + http://drupal.org/project/messaging module. You can set preferences for automatic subscribing to content type. Maybe Rules module can subscribe users automatically after creating or updating content_profile. Or maybe Rules can flag users after creating or updating content_profile and Subscription module could autosubscribe flagged users.