I have to send several emails (3000) from drupal 8. Each email must have a single-use link that points to the same page. All emails are saved in a custom entity (not the registered users of the site).
When the user clicks on the mail link I have to check that the link has not already been used.
I suppose that in addition to the mail, you have to save a single parameter in the custom entity (token?). And when the user clicks on the email link I look if the parameter exists and if it has not already been used.
How can I do that?
Thanks for your help.
The implementation depends on what exactly you are going to do. The simplest way to ensure than the link was used only once is to set a cookie. Sure, it's not the most reliable way (you can delete cookie or visit the same link from different device/browser), but it can be enough for certain scenarios.
If you need more reliable solution, I'd suggest you to implement a custom route controller that accepts a token as a url parameter and check it against your tokens.
You can store them as an array ['token' => 'some_hash', 'used' => 0] in Drupal sates
Related
How can you check that an email address already exists in spartacus? The reference class for this type of query would be UserService. But it does not contain this kind of method or anything simillar.
In the past, we had this functionality built in. But because of security reasons our backend is not sending us any feedback about email/password/account being incorrect/existing/etc anymore. So even if you'd do anything on the frontend, the backend will not help with that.
Here's one of the PRs, where we had to change the register flow - before, it was logging you in automatically once registered successfully, but if your email was already used, it wasn't logging you in - boom, security issue (possibility to check if a given email is used on this specific site)
So, unless you customize your backend (not sure if even possible), you cannot really check if email already exists in Spartacus.
Being in a view and you know the area-name, controller-name and action-name of a destination to which you want the user to provide a link to, how can I figure out if the area/controller/action is authorized for the authenticated user.
Imaginary Use-case:
I have a table with a list of books (the result of bookscontroller.index). To the far right are some icons to edit or delete a specific book. The edit link refers to bookscontroller.edit and the delete link to bookscontroller.delete.
On the actions there are custom authorizationattributes and this works perfect. If a user want to access books/edit/1 and the user is not allowed to edit books, the user gets redirected to the logon page.
It is a bit stupid to have that edit-icon there if the user is not allowed to edit books. So at view level I would like to be able to figure out if the user is allowed to use the edit action of the bookscontroller. If he is, show the icon if not, do not show the action.
Goal: use that knowledge to create a custom tag-helper.
The go-to method is reactive, i.e. you check if a user can do action when the user tries to do. Since you do not want to go that way, here is how. (yet, this is anti-pattern)
Have the authentication token of the user send back to backend. The backend should have an API end point for each button on the page user can click. With the authentication token, the back-end resolve whether to dim or enable the buttons.
Now, what the backend does to resolve this is not very efficient. The backend needs to literally attempt certain actions and aborts the transaction. For create and retrieve, it is trivial (you can pre-resolve them) but for edit and delete, this requires a lot of resources.
The standard way of controlling such actions on UI is to use role based authorization.
For the buttons or other such UI elements, setup role tags, e.g. "admin:edit", "viewer:readonly" etc.
When you are authenticating a user, send the applicable roles from the backend server, store them in a way that is globally accessible to your UI and use them for filtering UI elements across your application.
I'm new to Piranha CMS and just trying to get my head around it. I'm using the MVC implementation and I need to do the following:
I need to extend the User with a property that stores an account number.
I need a page that is only accessible once the user logs in
On this page, I need to call a REST API on another server, using the account number a parameter, to retrieve a list of documents that the user has stored on this server.
When the user clicks the document, it will be downloaded as a PDF using the REST API once again
I just need general guidance on how to do this. How do I store the account number against the user (and manage this) and do I need to create a new Region that will show the list of documents from the remote server. Is there an example of creating a new Region anywhere and maybe returning a list from SQL that I can adapt?
Any help gratefully received.
Thanks in advance
Mike
The easiest way is to implement an extension with your custom fields that you attach to the user where you store this information.
When editing a page, go in under "settings" and select which groups should have access to your page. For this purpose I suggest creating a new group for site users that are not admins.
This should be easily implemented in either the controller or model for your page. When the user is logged in "User.Identity.Name" is the user id. Get the user, load the extensions & use the account number.
See number three.
Regards
Imagine a simple REST API that allows to create a user account, by sending a JSON resource to POST /users as in the following. By default it sends out a confirmation email to the user.
{
"username": "john#appleseed.com",
"password": "secret"
}
However sometimes there are good reasons for not sending out a confirmation based on the use case, e.g. another API client, or admins signing up users on their behalf.
Since it doesn't have any implications on the created resource but is more of an instruction how to create the user, should it be separate from the request body? What's the best way to do this?
Specify a custom header Confirmation: no-confirmation
Add a query param ?confirmation=false
Add a send_confirmation field to the request body
Let's take the options in order:
Adding a header value to indicate some semantic difference should be generally avoided. The API should be "browseable", meaning it should be discoverable following links only.
Adding a query parameter is, from REST perspective completely equal to creating another URI. It does not really matter how you expose it, the point is that the client needs to follow some links from the previous "state" it was in. This is actually ok, as long as the links to these resources indicate the different semantics you described: like creating users by admin, users creating themselves, etc.
Also note, that the API should not necessarily expose whether a confirmation is sent. The API should expose the "purpose", the server then can decide whether the use-case warrants a confirmation email.
Putting a send_confirmation in the JSON representation itself. This is ok, if this is a functionality available for the user. For example I can ask for a confirmation email. If I can't, and it is only used for differentiating different use-cases, then I would rather prefer option 2.
Summary: For the case you are describing I would pick option 2: different resources for admins and normal users.
In my application I allow users to connect their Facebook accounts via oauth for the purpose of posting via our interface. We support both page accounts and regular accounts that simply manage pages.
We also inspect the result of the opengraph API call to get a valid URL to their profile, or page. The primary endpoint we use is https://graph.facebook.com/me (with oauth credentials). For some page-only accounts, the returned object has a 'link' value that, when entered into a web browser, 404s.
The bad URLs I have seen fall into two distinct cases:
The URL can be of the form 'www.facebook.com/{page_id}' which 404s on some pages, but not others.
The URL can be of the form 'www.facebook.com/profile.php?id={user_id}' which more often than not 404s.
The only URL format I have seen that works for all accounts is www.facebook.com/profile.php?id={page_id}. In the first case, we detect that the 'link' field isn't of the proper form (using profile.php?id=...), and construct a URL with the proper structure, and it works.
My next heuristic I'm considering adding is to see if the URL is of the proper form....but uses the {user_id} as the id argument to profile.php, and just construct the URL using the {page_id}. Obviously, this is getting ridiculous.
So, is there a good way to know if an account will give back a link that is invalid? Is this a bug in the API? What is the most reliable way to, given a User on the open graph API, to get a working link to their profile/page?
Using 'www.facebook.com/{page_id}' or 'www.facebook.com/profile.php?id={user_id}' will always work - they are both the same. The only reason you'll see a 404 is if the Page has been unpublished / deleted or if the user has deactivated their account.