If I use a simple rails c command to open my development console, and fetch my customers with:
Balanced::Customer.all
I not only get results, but I can use:
customer = Balanced::Customer.all.first
customer.name = "Joe Bob"
customer.save # this works, returns true
customer = Balanced::Customer.all.first
puts customer.name
And the result will indeed be "Joe Bob".
I'm not sure what exactly "For security concerns regarding submitted data, all your requests MUST occur via https." means, if it doesn't seem to be true... Maybe I'm missing something?
The request your system is making to the Balanced API occurs over HTTPS. It does not mean that you need to run a web server over HTTPS however, it would be strongly recommended.
The interactions between your Rails application and Balanced always take place over HTTPS. The part of the documentation you quoted is referring to these interactions. This does not remove the need for you to use SSL on your servers in production as all financial transactions should occur over SSL.
Related
Over the last couple days I've been getting millions of requests from rotating IPs. They're attempting to run post requests and seem to be using an incorrect HTTP_ORIGIN. By incorrect, I mean that it's not the same as what my server sends:
My server sends: "https://www.example.com"
The spam request sends: www.example.com
I placed some logging for each scenario:
User logged in and has incorrect HTTP_ORIGIN
User NOT logged in and has incorrect HTTP_ORIGIN
What I've noticed is that there are users that are logged in, but have the wrong HTTP_ORIGIN (origin is missing "https://". I have checked those user accounts and while they appear to be real, and not created by the original spam requests, they may be currently run through scripts.
It seems like it would prevent those users from accessing the POST requests of the site, but on the other hand, if they were real users, it would cause a problem.
Now if I were to put filtering in place to block requests that didn't match the origin, my questions are:
What would be the side effect of that?
Are there downsides or negative aspects?
Would I see drops in traffic?
If that so, It's like you said some are using your website from scripts, considering if your website is normal (I mean not like a website to upload data or sth like that), then it would be good to consider adding captcha to your website in place of filtering requests (cause I think it would be simple for those who send incorrect HTTP_ORIGIN to make a similar one to the original if they use a sslstream especially if it is for malicious goals).
And for the consequences if you use a filtering to the http request, I think the requests will drop remarkably (since you will refuse incorrect ones), and some real users who use scripts will switch to browser (it's a rare case especially if they scrape data from website in an automatic way) or they will stop using your website.
You need to wait for further research and make sure that those false requests are not malicious ones (perhaps they are using simple tcp client). Either way it is best for the time being to inspect data sent in the POST requests (incorrect ones) and see if there is some suspicious data (In that case you should use some safety method in your website)
I am trying to accept a HIT as a worker from sandbox but every time it shows following message.
"Your request for the Qualification "Categorization Masters" has been submitted to Requester Amazon Mechanical Turk"
Can anybody say what I am missing here.
The sandbox works just like the live site, as in you (as a worker) have to be meet the qualifications in order to accept a HIT. This means if you're trying to complete your own HIT in the sandbox just to try it out, you have two options:
Remove the QualificationRequirements from the HIT so you can complete it.
Obtain the necessary qualifications in the sandbox in order to satisfy the requirements.
Option 1 is easy (and is what you should do). Option 2 is difficult, or maybe impossible.
We have a single-page app (AngularJs) which interacts with the backend using REST API. The app allows each user to see information about the company the user works at, but not any other company's data. Our current REST API looks like this:
domain.com/companies/123
domain.com/companies/123/employees
domain.com/employees/987
NOTE: All ids are GUIDs, hence the last end-point doesn't have company id, just the employee id.
We recently started working on enforcing the requirement of each user having access to information related exclusively the company where the user works. This means that on the backend we need to track who the logged in user is (which is simple auth problem) as well as determining the company whose information is being accessed. The latter is not easy to determine from our REST API calls, because some of them do not include company id, such as the last one shown above.
We decided that instead of tracking company ID in the UI and sending it with each request, we would put it in the subdomain. So, assuming that ACME company has id=123 our API would change as follows:
acme.domain.com
acme.domain.com/employees
acme.domain.com/employees/987
This makes identifying the company very easy on the backend and requires minor changes to REST calls from our single-page app. However, my concern is that it breaks the RESTfulness of our API. This may also introduce some CORS problems, but I don't have a use case for it now.
I would like to hear your thoughts on this and how you dealt with this problem in the past.
Thanks!
In a similar application, we did put the 'company id' into the path (every company-specific path), not as a subdomain.
I wouldn't care a jot about whether some terminology enthusiast thought my design was "RESTful
" or not, but I can see several disadvantages to using domains, mostly stemming from the fact that the world tends to assume that the domain identifies "the server", and the path is how you find an item on that server. There will be a certain amount of extra stuff you'll have to deal with with multiple domains which you wouldn't with paths:
HTTPS - you'd need a wildcard certificate instead of a simple one
DNS - you're either going to have wildcard DNS entries, or your application management is now going to involve DNS management
All the CORS stuff which you mention - may or may not be a headache in your specific application - anything which is making 'same domain' assumptions about security policy is going to be affected.
Of course, if you want lots of isolation between companies, and effectively you would be as happy running a separate server for each company, then it's not a bad design. I can't see it's more or less RESTful, as that's just a matter of viewpoint.
There is nothing "unrestful" in using subdomains. URIs in REST are opaque, meaning that you don't really care about what the URI is, but only about the fact that every single resource in the system can be identified and referenced independently.
Also, in a RESTful application, you never compose URLs manually, but you traverse the hypermedia links you find at the API endpoint and in all the returned responses. Since you don't need to manually compose URIs, from the REST point of view it's indifferent how they look. Having a URI such as
//domain.com/ABGHTYT12345H
would be as RESTful as
//domain.com/companies/acme/employees/123
or
//domain.com/acme/employees/smith-charles
or
//acme.domain.com/employees/123
All of those are equally RESTful.
But... I like to think of usable APIs, and when it comes to usability having readable meaningful URLs is a must for me. Also following conventions is a good idea. In your particular case, there is nothing unrestful with the route, but it is unusual to find that kind of behaviour in an API, so it might not be the best practice. Also, as someone pointed out, it might complicate your development (Not specifically on the CORS part though, that one is easily solved by sending a few HTTP headers)
So, even if I can't see anything non REST on your proposal, the conventions elsewhere would be against subdomains on an API.
I have a problem with the Express Checkout. I tried all the solution provided in the web but I cannot make it work!
I'm using VB 2012 for Web and ASP.NET. I built a cart in the web site and try to integrate PayPal Express Checkout (for now using the test account in Sandbox).
When I click on the PayPal button it shows me the error:
10001 Internal Error: Timeout processing request
Debugging the application I found that the problem is when he try to make the call:
Try
Using myWriter As New StreamWriter(objRequest.GetRequestStream())
myWriter.Write(strPost)
End Using
Catch e As Exception
End Try
Where strPost is the following:
METHOD=SetExpressCheckout&RETURNURL=http%3a%2f%2flocalhost%3a63223%2fCheckout%2fCheckoutReview.aspx&CANCELURL=http%3a%2f%2flocalhost%3a63223%2fCheckout%2fCheckoutCancel.aspx&BRANDNAME=PayPal+Sample+Application&PAYMENTREQUEST_0_AMT=36&PAYMENTREQUEST_0_ITEMAMT=36&PAYMENTREQUEST_0_PAYMENTACTION=Sale&PAYMENTREQUEST_0_CURRENCYCODE=USD&L_PAYMENTREQUEST_0+_NAME=Modena&L_PAYMENTREQUEST_0_AMT=36&L_PAYMENTREQUEST_0_QTY=1&USER=minni_1356740302_biz_api1.gmail.com&PWD=1356740320&SIGNATURE=AlYEmGf5ECuFHhwJgGlXJ.tMCTY0AFMcAx3nUjv6Ssg4RlD7YYwyoOJb&VERSION=88.0&BUTTONSOURCE=PP-ECWizard
What could be wrong?
I really need help..Any and all help is appreciated.
Thanks in advance!
This error could simply mean there's an issue with the PayPal sandbox servers, or it could mean you have a problem with your request. I was able to successfully hit the sandbox with SetExpressCheckout just now, though, so I'm guessing it must have something to do with your request.
One thing I see right away is that you won't be able to use localhost in your ReturnURL and CancelURL because at the time that gets used it will be running from PayPal's server. As such, "localhost" will be their server, not yours, and the redirect won't work. You'll need to use your own public IP address or setup a domain of some sort to point to your test server. That could be what their server isn't liking.
Another thing I notice is that you're just using the value 36 for your amounts. PayPal documentation specifies you need to use two decimal places on amount values, so you need to make sure and pass 36.00 instead.
The next thing I notice, which is probably what's causing your problem, is that one of your parameter names is invalid: [L_PAYMENTREQUEST_0+_NAME]
You need to get that + out of there. I bet that'll fix your issue, but I'd still get those other things fixed up, too.
Some browsers show a security warning when paypal (auto) returns a customer after payment to a non https page. This is quite annoying. The obvious solution that has been given was to get a https certificate.
I assume the trouble comes from paypal submitting form data on the return.
Is it is somehow possible to tell paypal to return the customer without any post/get data? Then the warning should not show up. Customer data coming in as post/get is not reliable anyway. In my case customer identification is not even necessary (a simple "thank you" would be enough) and can be done via the session anyway.
I realize this may be a question for a paypal support forum but I have not yet found the right place to go. :)
edit 2012-01-24:
while I think it is quite funny that the hack below works I found the official and much better solution by setting rm to 1:
from https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_Appx_websitestandard_htmlvariables#id08A6HI0709B
rm
Return method. The FORM METHOD used to send data to the URL specified by the return variable.
Allowable values are:
0 – all shopping cart payments use the GET method
1 – the buyer’s browser is redirected to the return URL by using the GET method, but no payment variables are included
2 – the buyer’s browser is redirected to the return URL by using the POST method, and all payment variables are included
old hack:
using javascript I found a way to do it. I put some javascript code in the return URL that sends me home without the submit data.
$p->add_field('return', "javascript:window.location = 'http://mysite.com?p=thanks';");
paypal site needs javascript anyway.