the company I work for want to use a "hosted payment form" to charge our customers. A question came up on how we can populate the "payment form" automatically with information from one of our other system. We have no control over the hosed payment form, and we have to use IE. Is this possible at all? And if so, how can this be done?
If something is unclear, please let me know...
Assuming that you are essentially embedding the contents of a remote form in a frame/iframe, the you should be able to use some javascript to set values for the fields - field.value = "xxxx".
That solution of course depends on the form remaining the same - any changes to the remote form will require you to update your script.
If you are "handing off" to a remote site (redirect) that post's back to your site when payment is complete, then unless the remote site offers an API / a way of passing request parameters through, then you are going to be out of luck,
Unless your payment gateway allows you to pass through data in a set API (which lots do!), you'd need to take control (and responsibility) for your payment form.
I say responsibility because you would have to prove to your merchant account provider that everything is secure. This will probably incur some security testing fees too.
So check with your merchant gateway first. Lots of systems have the means to accept data from your site and their tech support will be able to give you a straight answer immediately. Otherwise you'd have to switch it over so you process all the data yourself which, just for making things easier, isn't worth it IMO.
Related
I want to build an "audit trail" for all requests incoming to the server, however it needs to be specific per user, per web page.
For instance I imagine something like this:
On initial view render I would store (cookie/ page variable/ something else) a unique Id saying the user browsed to /myapp.com/dashboard/1234. - maybe in the layout.cshtml.
Then the app fires off X number of GET/ POST requests to the server each having that same unique Id initially tied to the view rendered.
This allows me then to tie back all requests for a page and add up the server execution time.
I tried using path specific cookies but this won't work I realized since a user can have many tabs open with the same url. Also the user works in many areas of the app at once. They can have anywhere from 1 to 10+ tabs open. Each of these should have it's own unique Id and "audit trail" of all calls taking place on that page.
This is an existing app so modifying each of the GET/ POST to pass in the unique Id is out of scope. Just hoping I am missing something that might take care of this.
Thank you!
If I'm understanding you correctly, you have a single page load, and then additional requests made either for images and other resources or AJAX requests that you want tied to and tracked along with that initial page load.
The chief problem you're going to have here is that, based on the way HTTP works, each request is handled as its own thing and not considered as part of a greater whole. The web browser makes it all look seamless, but all the web server is doing is just responding to a bunch of (as far as it knows) unrelated requests for various different things. To track them all as one unit, you would either need to attach some unique id to the request itself (for a GET, that would be either as part of the URI path or query string) or lean on Session to introduce state between the requests. However, session state really only works in this scenario when all requests can be tied to a single initial request. Once the user starts working with multiple different pages at once, there's no reasonable to discern which request belongs to what, and you're back in the same boat.
In other words, your only real option is to send something along with the request, which would mean doing something like:
<link rel="stylesheet" type="text/css" href="/path/to/file.css?origin=#Request.RawUrl" />
Then, you could have an action filter that looks for origin in the query string of any request, and ties it to the logging for that particular page.
For what it's worth, it should be noted that by default, IIS will handle all requests for static resources directly, without involving ASP.NET. If you do want to track requests for static resources, you would have to pass them all through ASP.NET, which will be kind of a pain. If you only want to track AJAX requests, that's much simpler and shouldn't require anything special for the most part.
All that said, if the only purpose of this is to track page load time, there's far better and easier ways to do that. You can install Glimpse. You can use your browser's developer console. You can use something like Google Analytics. All of these are far preferable to the path you're going down here, for page load statistics.
Write an ActionFilter to do this. There are many examples of this
http://rion.io/2013/04/15/creating-advanced-audit-trails-using-actionfilters-in-asp-net-mvc/
http://blog.ploeh.dk/2014/06/13/passive-attributes/
I personally like Mark Seemann's example more since it clearly defines a nice separation of concerns for the attribute and the filter.
I have few questions concerning PayPal and Classic API. I have spent the last few days reading and experimenting with 1. Single PayPal Payment using variables and HTML post form. 2. Idem but for recurring/subscription payments. Even though I almost succeed to do most of what I want to accomplish, I still have few questions and grey zone I'd like to debunk.
Here it is:
Is it possible to use classic API, HTML form, PayPal variables and post a request to PayPal/Sandbox AND ONLY use credit card information, without having to log in PayPal or have a PayPal account? I never succeed and PayPal always block after you hit the PAY button, returning security codes error message or wrong card/account number etc.
If yes, how and where can I find a real code sample or demo for HTML/MVC-C#?
After a make a payment, I receive an invalid response which nothing happens, then, I receive a second IPN response and this one is verified etc. DO I really need to reply to PayPal/Sandbox to tell them everything is OK? If yes, is there info somewhere or code sample/demo I can see? MY point here is because i receive MANY hits on my IPN and I want to make sure I get the right response, make sure i don't DOUBLE subscribe etc..
Is there A GOOD MVC or C# IPN code sample somewhere? One I could read and analyse/take to handle most possible scenarios/errors/response code and what to do with them? not to copy and paste but something reliable I could adapt to my code.
I have succeeded to get a response to my IPN with a PayPal account only and I had to somehow hack security protocol using this instruction --> ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;//SecurityProtocolType.Tls1.2; and I also had to use ngrok to provide a 'valid' return URL. My question here is, Do I Need to remove that instruction when I go PROD?
Thank you so much in advance,
Mart.
Yes, but this is one of the reasons the question got voted down. You need to sign up for Payments Pro to do credit cards (or you could also use the REST API) and then you would use those specific APIs to process credit cards. The thing is, depending on what version of Pro you end up with or if you decide to go with REST, the APIs are different, so it's hard for anybody to tell you what to use at this point.
Yes, you need to POST back to PayPal to verify that the data actually came from them. This way you can trash any data where wannabe hackers are posting garbage to your IPN listener or anything else like that going on.
As long as your IPN script completes with a successful 200 response back from your server then PayPal will only send a single IPN. If you're getting multiples you must have a failure going on, in which case you'll need to troubleshoot that accordingly.
Yes, PayPal provides lots of sample code. This is another reason your question may have been voted down. It seems you have not taken the time to look into this stuff yourself. Go to http://developer.paypal.com and upon reviewing the APIs you'll find they provide SDKs for different languages. Each of those comes with samples, and their GitHub repos also include samples.
With a quick Google search you'll find loads of tutorials and samples as well, of course.
Within the developer site you'll also find the Integration Wizard, which will let you choose C#, choose the payment integration you want, and it will build it all for you so you can see how it works.
Then, when working on those samples or trying actual code, if you have specific problems / questions, you'd come here and post that specific issue with a code sample that you've tried. Then people here will be happy to help.
TLS 1.2 is a standard requirement for pretty much all web services now because of security vulnerabilities in SSLv3. If you have "hack" anything (outside of configuration files, maybe) then you're probably doing something unnecessary. All it would require is to ensure the software stack on your server not only supports TLS 1.2 HTTP requests, but also uses it by default.
I am not a programmer, but for some reason I do program here at work to do some apps that makes out job easier. Anyway, this "some apps" has grown bigger in years. I've always had problems in understanding security or authentication related things, so I do it my way (which is indeed way way way far from being right). I use C#, mostly with client/server apps using WCF.
The issue now is in my methods in WCF. All of them are similar to this:
public Employee AddEmployee(Guid sessionID, Employee emp)
{
Session session = Common.CheckSession(sessionID);
// do stuff
}
As you can see, the sessionID is passed to every call to the WCF. This ID is generated once the user login using another WCF method. A row in the database is created and the 'CheckSession', which is called in every single method checks if the session is valid and if the user is allowed and so on. The connection is secured using SSL.
How wrong is this? Can I just keep do it for now? Or should I just stop it because it is so messed up, and start figuring out the right way of doing it?
if you squint your eyes and turn your head to the side a bit, this is kind of how authentication works.
Except, WCF uses an encrypted layer to send messages so no one can spy on your session / authentication / data information
It does a similar check, not per call, but it hooks the calls (which you could do too) right at the beginning, checks the authentication, then passes it on if its allowed to.
Thats just for authentication (working out that you are who you say you are). Security, whether a particular user is allowed to perform particular actions is controlled through things like "Roles". But you may have to build in even more checks if you have more fine grained security concerns.
Now inventing that yourself? Not a good idea. Too easy to have holes your method.
While going through MVC concepts, i have read that it is not a good practice to have code inside 'GET' action which changes state of server objects( DB updates etc.,).
'Caching of return data' has been given as a reason for this.
Could someone please explain this?
Thanks in advance!
This is by HTTP standard. The GET verb is one that should be idempotent and safe.
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Browsers can cache GET requests, generally on static data, like images or scripts. But you can also allow browsers to cache GET requests to controller actions as well, using [OutputCache] or other similar ways, so if caching is turned on for a GET controller action, it's possible that clicking on a link leading to /Home/Index doesn't actually run the Index method on the server, but rather allows the browser to serve up the page from its own cache.
With this line of thinking, you can safely turn on caching on GET actions in which the data you're serving up doesn't change (or doesn't change often), with the knowledge that your server action won't fire every time.
POSTs won't be cached by the browser, so any POST is guaranteed to make it to the server.
Ignore caching for a moment. Another way of thinking about this is that search engines will store HTTP GET links during their indexing/crawling process, therefore they will show up in search results.
Suppose if your /Home/Index is implemented as GET but it lets say deletes a row in your Database, every time this link shows up on a search engine and somebody clicks it, you will have a delete row, and soon you have a lot deleted rows.
The HTTP spec states that GET and HEAD are expected to be idempotent, ie. they should not change server state.
One practical aspect of this, is that search robots will issue GET against any link to your site they know of. If such a GET changes user data it was not meant to change, you are in trouble.
Being idempotent has the added benefit that clients could be able to cache the result of a GET (use HTTP headers to control this).
I have to implement a payment gateway for a website I am maintaining, and I haven't done anything like this before. Previously to implement payment processing, the site would build a transaction and send it directly to the payment processor and await a result. Since the site handled the gathering of credit card information, building of the transaction, and the requests/responses, there wasn't much I had to worry about that the previous developer hadn't already covered.
Now that I'm implementing a payment gateway, is there anything I should be checking or verifying?
The way this processor works is, I build a form that has the order id, amount, currency, etc. in hidden fields. That form is posted to the gateway, which will handle the processing, and then post a form back to our server where we can update the shopping cart and complete the order.
The only thing I can think of is a user modifying the form fields before we post them to the gateway. Such as adding a $100 item and changing
<input name="amount" value="100.00" type="hidden">
to
<input name="amount" value="0.01" type="hidden">
So when I receive the post I have to verify that the amount paid for was equal to the amount owed. Is there anything else I am missing? The implementation documentation doesn't even mention a scenario similar to the above, so I'm a little worried I'm missing other things and leaving the site open to further exploits.
I think you'd be better off creating a dedicated web service to handle this '3rd party' conduit architecture you have going on here, your basically playing the middle-man and an HTML form just feels like unnecessary overhead to me, unless it's required to be done that specific way, I'd move to a web service.
That being said, treat it like any client application, don't trust whatever they give you, validate and cleanse the information as necessary before performing the operation.
I would also recommend building or integrating support for logging into your middle ware system, so should a problem arise, you have some way of capturing issues and tracking them for the future, bug fixes, support calls, etc.
It's probably obvious but make sure to validate your order #'s, a user could put anything in there they wanted, again, validate and cleanse the data and log the truly weird situations.
First, I have to agree with Capital G. It would be so much easier to just make a server to server connection than to try and handle form submission through the client browser.
One thing to check: after submitting to the gateway, does the client then initiate the post back to your server, or does the gateway server handle it? If the client initiates it, what prevents them from POSTing to you that the order is complete without ever having gone to the gateway? It sounds like you might need to make a webservice request to the gateway to verify the payment actually went through before accepting the client POST that claims it did.
Could you add a digest to the communication? If you had a shared secret with the gateway you could validate the integrity of information shared even if it passed through the client by including a digest both ways.
Make sense?
Carl
First, I don't think you're implementing a payment gateway. It sounds like you're just using one. If this is wrong, just ignore the rest of this answer, and I'll delete it when I can :)
Using a Payment Gateway from a Simple HTTP Form
Google Checkout -- as one example -- allows you to use an "unsigned cart" like the one you describe. The other option is to post via the web service interface, and do correct error checking etc.. When you submit an order with an HTML form, Google Checkout warns you, the merchant, that the "cart is unsigned" (later in the admin screen). This means that the information in the cart -- especially prices -- is not to be trusted. The fact that the end-user put in their credit card basically vouches for the fact that the transaction is okay with him/her. So you just have to check that the numbers used to arrive at the final totals -- or amount owed, or whatever your business is -- check out. So what you're doing is fine on a low-level.
The reason you should use a web-service submit to the service -- and secure signing of the cart, etc. -- is... What do you do if the numbers are wrong? Call the end-user up and explain the situation? So that's a bit tricky, because you cannot assume fraud. There are many strange reasons for which the cart would be altered without the user actually wanting to scam you.