I'm developing a simple JavaScript application for an insurance company, where users can calculate their monthly fee on one website and then will be redirected to another website where they can fill their insurance application. The calculator app will run on the websites of multiple resellers, eg www.reseller.com. If a user presses "calculate", an ajax request to www.insurance.com calculates the results and generates a hash as a unique identifier for the calculation and sends it back to www.reseller.com. If the user agrees to the result, he can go to www.insurance.com/order, where he can place the application.
What's the best way to share the calculation hash with both domains without using get parameters?
I've already tried to set the hash value as a cookie in the ajax result on reseller.com, but since the cookie is placed on the same domain, the final order form on insurance.com can't read it.
Is there any way?
Related
Beginner question here. I’m wanting to build an app that will be an intranet of sorts for a 70 unit restaurant chain. What I’m needing is for each physical restaurant location to see data posted to a MongoDB DB and show on a page in the store within a screen hanging on the wall. This data will be specific to each location such as announcements, catering orders that need to be filled by that store, etc... my question is, how do I create routes so that each individual store will see only their data without having to create 70 different routes or use authentication to utilize user IDs?
Trying to avoid user logins and:
“/store1”
“/store2”
“/store3”
Etc...
Seems like I could query a site ID or something like that
Hope this make since.
If you're talking about one centrally located server that is accessed by all 70 restaurants and you want to have the same routes for all, then you need to decipher some other clue from the request to figure out which restaurant it is that is making the request.
Since you have nixed authentication, I will assume that there are no security concerns here - that this is on an intranet only accessible by restaurant employees.
So, here are the clues you could get from any given request to decide which restaurant's data to show:
Cookie that contains desired restaurant ID.
Query parameter that contains desired restaurant ID.
IP address of request to discern which restaurant the request is coming from.
Separate sub-domain for each restaurant (all pointing to the same host).
Here's more info on each option:
Cookie
In this implementation, if a client arrives with no cookie set for the restaurant ID, then you take them to an opening page where they select which restaurant they want to see the data for and you ask the user to manually select the desired restaurant. Then, you set a long lasting cookie in that browser and from then on (as long as the cookie is not removed), your server can default to showing them info only for their restaurant.
Query Parameter
In this implementation, you use some initial restaurant specification like in the cookie option and then you generate pages where all the links have a query parameter specified in them that lists the restaurant ID (likely using a template system). This is generally not favored these days over a plain cookie system.
IP address
If all your restaurants have their own sub-network (presumably some sort of broadband connection connecting to a central server over some sort of private connection, then you could perhaps build a small table of restaurant source IP addresses so you could identify which restaurant was making the request purely by the IP address of the request. This may or may not be feasible depending upon your network topology. This would be much more automatic than any of the other options.
Separate sub-domain
This would work somewhat like the cookie-based option, but instead of setting a cookie, once the desired restaurant was selected, you would redirect to a subdomain specific to that restaurant. All sub-domains would still point to the same host, but the host could identify the desired restaurant from the sub-domain making the request. Similar to the query parameter option, you'd some template system on the server side to rewrite all links to include the proper sub-domain so you'd stay on the same sub-domain as you navigate.
Of all of these options, the IP address scheme is the only one that would be completely automatic, but may or may not be feasible depending upon your network topology. Of the other choices, the cookie is the most straightforward to implement because the page links themselves don't have to be rewritten.
Enterprise Configuration
In an enterprise scenario where you "manage" any browser that is approved for use, you may also be able to pre-configure the browser in each restaurant to automatically provide some identification (either a custom header or a cookie) and your server could use that identification info to determine which restaurant was making the choice. This would require accessing your site only through pre-configured and approved and properly maintained browsers (which may be more pain than it's worth).
For example, here's how you would configure a custom header on all requests with Microsoft Edge.
I am making an app with local Html files inside the assets folder in android studio. When opened it first open index.html files as specified. As it is routine application, I was wondering if I could add Remember this functionality, such that when user loads application, they'll get automatically redirects to the same page they have checked and also provides Reset in case they want to reset their choice in future.
Any Help would be greatly appreciated.
Improved Persistent Login Cookie Best Practice
You could use this strategy described here as best practice (2006) or an updated strategy described here (2015):
When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.
The login cookie contains a series identifier and a token. The series and token are unguessable random numbers from a suitably large space. Both are stored together in a database table, the token is hashed (sha256 is fine).
When a non-logged-in user visits the site and presents a login cookie, the series identifier is looked up in the database.
If the series identifier is present and the hash of the token matches the hash for that series identifier, the user is considered authenticated. A new token is generated, a new hash for the token is stored over the old record, and a new login cookie is issued to the user (it's okay to re-use the series identifier).
If the series is present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
If the username and series are not present, the login cookie is ignored.
This approach provides defense-in-depth. If someone manages to leak the database table, it does not give an attacker an open door for impersonating users.
I'm creating a widget that shows content when the page visitor pays for it. I'm handling the payment form inside the widget and I'm using Stripe for credit card handling, charges, etc.
My problem is: I want to make it easy for the user to pay for the content, right now, I'm my working proof of concept I only ask for the email, then:
Check if I already have this email on my system, check with my API server if it has a payment for this product associated and then let the user get to the content.
If the email is not present in the system, it is created, and return only the Stripe publishable key.
If the email is present, but it has no payment associated with this product, simply return the Stripe publishable key.
When the widget gets the Stripe key, then it shows the payment (credit card) form, which is used to get the Stripe token, and this token, along with the email, is sent back to my API server. If everything is Ok, then the widget retrieves the content and shows it to the user.
Now, the question(s): How to secure the communication between the widget and the server, besides using HTTPS? I already have support for application id/secret pairs, how can I use them to to authenticate the requests from the widget to the server? The widget will be inserted in pages on arbitrary domains, so using the Referer/Origin headers is out of the question.
I don't think that is really important, but if it helps, I'm using Django 1.7 and Django Rest Framework 3.0.5.
Thanks!
There is an api you can use, called CoinTent. Its sub-motto is "Purchase individual pieces of content for small prices with one account and one click." HEAD HEAD HEAD HEAD...
I'm creating a very simple store with literally one product where the user can choose different options and, dependant on the options selected, this will generate the total cost for the item. So for example, if the user selects the red variant, the price will increase by 5%, if the user selects the blue variant then the price will increase by 10%.
Currently I'm making the calculations with jQuery and then passing them to an empty field which is then posted to a payment gateway. Is this method safe? Theoretically, a user could open up Firebug or Chrome Developer Tools and edit the value (to zero) before posting it to the gateway but couldn't this apply to similar methods of product variation calculations? I'm trying to figure out whether or not this is an issue, but is there a better way?
This is definitely an issue, as you said yourself a user can modify the values.
So, you would show a price to the user on the client side, it doesn't matter how the value is generated because it will never be trusted by the server and will never be passed to the payment gateway.
User presses "buy now", is redirected to the payment gateway, but via your own server first. The server should validate the product and calculate the price.
The final price (calculated by your own server) will be shown to the user at point of payment.
On the client side you could either continue to generate the values with JQuery, or have the server return them via an AJAX request. But this would only be for user experience, the values could not be trusted.
If you choose this method, you sholud probably store product configuration (like string represenetaion od JSON or comma delimited field, etc.) in a hidden field, calculate the price (client or server side) and show price only as an information to a customer.
When he submits the configuration, validate it and calcuclate pice again on server.
That way customer could change the configuration (trough Firebug or so), but could not change the price since it is calculated based on a configuration.
Well, that is how i would do it.
After a PayPal payment been proceed, PayPal sends IPN(Instant Payment Notification) message to the url you specify.You have to resend it to verify if the message is original from paypal. After that, to be sure the user payed the right amount of money you get the values from IPN (it may come with user Id. transaction ID and so on...) and check them with your DataBase.
Some useful links:
More about IPN
Paypal Developers Guide
Pyapal IPN
Rule number one in e-commerce website: Never trust Users
So, this is the right process:
After calculations with jQuery and then passing them to an empty field which is then posted to a payment gateway, store the user name/id, transaction, and amount in database. Create method that verify, the stored values with the IPN response from paypal.
If values match, payment succeed. Else, mark it for later hand verification(you should store the id so it is easier to find on paypal).
I am making a website for a school club (a FIRST Robotics team) and we rely heavily on donations. I am looking for a way to display information about donors if they choose to have it displayed. The biggest problem is that the server it is on doesn't work well with most server-side code so I am limited to HTML/CSS, JavaScript and PHP.
The way I have thought of doing this is having a form on the site which would send information they choose (I.E. a name/company) to a google spreadsheet and then somehow have the PayPal payment confirmation be sent to the spreadsheet as well to prevent people from just sending whatever information they want to the spreadsheet.
So: Is it possible to get a PayPal payment confirmation sent to an arbitrary source in a format I specify? If so, how would I go about doing this? If not are there any other ways I can achieve the same result (display donation information on my website without server-side code)?
Paypal's buy now buttons don't require any server side code unless you want to know or store if the transaction was successful on the site. Check out this: http://paypal.github.io/JavaScriptButtons/