I have a widget for user to get information regarding books. The UX of the widget changes according to the fact that the user is logged in or not. Now I have a route for logged-in user(say, /user/getBookInfo) to get the book information(which includes sending sms n email logic). For users who are not logged-in I have created a different route(say, /public/getBookInfo), which includes some additional processing too. However retrieving the book information, sms and email logic etc is already present in '/user/getBookInfo'. I don't want to duplicate this function.
One option is call res.redirect('/user/getBookInfo') from /public/getBookInfo . However I want to avoid the redirect in this way.
So My question is How can I reuse this logic in /public/getBookInfo without using redirect??
Probably the best way in a Node.js application is to make a separate module, and put the common logic there. Then you can require the module in both routing files.
Related
I am using STRIPE as my payment processor, in an REACT + nodeJS app. I already have something that already works, but I would like some feedback, maybe I'm doing something wrong.
So... I have this Redirect-To-Checkout functionality thats made available by STRIPE, basically I redirect the user to this STRIPE page where all card-data (sensitive information) is processes in order for the payment to full-fill.
What I do in my nodeJS server part is the following:
Once the user acces the redirect to check-out page, I already create a PendingOrder, with the products selected by client (Here I save some information based on client/stripe payment-intent, in order to check in later steps)
Once webhook gives me the 'payment_intent.succeeded' I check for the payment-intent information to see if it exists in my PendingOrder collection, then proceed to add in to ConfirmedOrders and remove it from PendingOrders.
I have to do this whole process because Stripe no longer gives me access to some information I require when the user is checking-out his order(such as observation that the user has based on the type of service he chooses).
Are there any down-sides to this approach or is there any other way to do it?
Thanks in advance!
You’re not really far from the best practices that Stripe recommends here. The only thing that I would change is listening to checkout.session.completed instead of the payment_intent.succeeded event. As of the latest API version, a PaymentIntent is no longer created upfront so a better to way to handle order fulfillment is to either store the Checkout Session ID (e.g. cs_live_xxx) or you could add some metadata when creating the Checkout Session and use that instead to identify the order.
I have to do this whole process because Stripe no longer gives me access to some information I require when the user is checking-out his order
As for this, I’m not sure what you mean, you can always use your app with the success page customization described here alongside webhooks. I wouldn’t use that to fulfill the order though since the user might close the page before the redirection completes which means that the fulfillment wouldn’t be done in that case. As such, webhooks are essential to order fulfillment.
I'm currently building out a multipage form using Flutter (frontend) and Node/Express/MongoDB/Mongoose (backend) for which I would like to implement auto-saving as the user progresses through each page (ie. clicking the next button after each page saves form data to the DB).
I have client-side validation to ensure fields are filled out and in the correct format, but I believe server-side validation is more important to implement in the event the user bypasses the client-side. I was wondering if anyone had general design ideas/processes I could implement for this idea. Some ideas I have:
I'm thinking about sending a POST/PUT request to our server after each page, but I have no way of validating the incoming data server-side unless I create over 30 schemas for each of the pages. Each page has different questions so there isn't a single common validator I can use.
Another option was having a temporary object with all the fields, and only validate the object at the very end when the user clicks 'submit,' but this is bad UX design in my mind as any error may require the user to be set back to the 1st or 2nd page which is frustrating for sure.
My main concern is validating the incoming data on the server-side as well as the client-side, but I can't seem to think of a good way to do both in a clean manner. I believe this question is language-agnostic, but I added my tech stack just in case.
Any help would be greatly appreciated :)
So i have been struggling with this one question some time now:
How to handle details Page or deep linking on the Frontend.
So, say, we got a paged collection endpoint with user entities in it and a React App consuming the endpoint.
The flow would be, user authenticates, gets collections, clicks on an item and is either:
Redirected to a new Url say: webapp.com/users/userid
A modal opens with the user details.
Say we got a scenario were two people working with the webapp, Person 1 wants to share a link with Person 2. Person 2 should do some updates on a specific user, which is identified by the link.
The link should be something like : https://www.webapp.com/users/{slug or id}
With Option 2 this functionality is not mappable.
With Option 1 we got to expose the ids in the response to identify the resource, which may work, but we would still need to hardcode the url, as the findById method is not exported as a Uri Template.
So, my Solution would be to add a slug for the resources, implement a search method by the slug, and then get the user, if found, by its self-link.
Sounds like a good solution for me, but on the other hand, I would have to add an extra frontend id(the slug here) which would need to be also unique, to the database model.
So how do you guys handle a problem like this, or is there anybody using spring data rest in this way or in production mode where you have the handle situations like this?
Should mention that this isn’t a primary problem with spring data rest but rather with hateoas itself.
thanks in advance
Florian
You don't need to hardcode URL template. Spring data rest will generate links for each resource.
You can refer to it from front end by some format like: {your_user_object}._links.self.href
I'm hoping someone out there can help me understand how Stripe should work with Cakephp 3.
I have a form with the Stripe payment fields and a couple of fields for my cake app. From the Stripe documentation this seems to be an acceptable way to set it up.
The HTML is fairly standard, but note how every input for sensitive
data—number, CVC, expiration, and postal code—omits the name
attribute. By omitting a name, the user-supplied data in those fields
won't be passed to your server when the form is submitted. Each
element also includes a data-stripe attribute, to be discussed later.
I'm using cakephp 3 now which doesn't seem to allow me to remove properties from the HTML generated by the form helper. I can only make the 'name' property be blank. I queried this with Stripe support and they were a little noncommittal. They are generally very good but in this instance the answer seemed to be 'better safe than sorry.'
My main question is this: does it really matter if you don't use the form helper for Stripe fields. The main benefit i can find in the cake docs is that the CSRF component will act on those fields. I am using the CSRF component throughout my app, but since the Stripe fields aren't even sent to the server the CSRF component is irrelevant. Isn't it?
Here's an excerpt from the Cakephp manual:
The CsrfComponent works by setting a cookie to the user’s browser.
When forms are created with the Cake\View\Helper\FormHelper, a hidden
field is added containing the CSRF token. During the
Controller.startup event, if the request is a POST, PUT, DELETE, PATCH
request the component will compare the request data & cookie value. If
either is missing or the two values mismatch the component will throw
aCake\Network\Exception\InvalidCsrfTokenException.
I can still use the form helper for the few fields that do get submitted to the database, and just add the Stripe fields with HTML?
Does that make sense?
Stripe support did suggest having two separate forms, one for the cake data and one for the Stripe data, but since their docs say you can add the Stripe fields to a form that gets submitted to the server that seems a bit odd.
I would really appreciate some input on this as it seems even Stripe themselves aren't sure how to structure a cakephp payment form!
Yes raw HTML appears to be the way to go.
Here's what i did.
Used the form helper to start and end the form (This means form tampering and CSRF will work for your non Stripe fields)
Added the Stripe fields within the Cake form using HTML (I haven't tested the HTML fields to see if the form tampering works on them. I'll test that later and post back)
Used the Form helper to unlock the stripeToken field so it could be added to the form without the form tampering blackholing the request.
Once i set all this up I used echo debug($_POST) in my controller to see what the form was submitting to the server and the only Stripe field that was showing up was stripeToken.
So it appears to me that this is working as it should.
using php if that matters.
If you create a website that has users and groups. Where do you put this in the web application? Do you just put a function at the top of every page (pseudo):
if someone is in a group then they can see this page
or
if someone is in this group they can see this button
That sure seems wrong. I wouldn't want to edit the web app code just to change who can see what group-wise. I'm not sure what I should do or how to implement something like this.
Thanks.
In MySQL, I always create these 4 tables: users, user_groups, permissions and user_groups_permissions which are linked using Foreign Keys.
So, user A can be in a user group B, which this user group permissions are in user_groups_permissions.
Now, I just do a INNER JOIN on this 4 tables (or better, three: users, user_groups_permissions and permissions), the results are permissions that user have. all we need is selecting permissions.key by INNER JOIN.
Now, before processing request, I need to check that Client::has_permissin('send_post') returns true or not. And better, also on top of each user-group-related function.
Note: Client is a class that loads all user permissions just one time, before processing request, and then uses that permissions for whole request-life-time, without needing to access to database several times in that request. Use static methods and $permissions property for this class so you never need to send it's object over your applications classes/methods/functions :)
You can have a utility function which takes user id and group code and return true or false.
You can use that utility function as pseudo at the top of each page and the same function also be used to hide or show sections in your page.
If your web application is in MVC, embed user authorization logic in your controller.