Is there a way I can make a request to a different server than the one that's being used for development using a RequestBuilder?
I keep getting
com.google.gwt.http.client.RequestPermissionException: The URL
http://127.0.0.1:4321/getSellers is invalid or violates the same-origin
security restriction
while I am sending request from 127.0.0.1:8888
GWT currently doesnt support cross domain ajax calls - but it can be worked around if you are willing to do a bit of jsni. And I heard a rumour some time ago that there is a gwt patch with the solution, but its not perfect. see this http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c/
to work around using jsni, you can use whats called the windows.name transport - see this blog http://www.sitepen.com/blog/2008/07/22/windowname-transport/ . i havent been able to locate a library for gwt to automate this, but i dont think its too hard to do yourself in jsni (and dont me misled by the blog being about dojo, its a general technique).
There is a detailed explanation on the topic of the Same Origin Policy and its consequences for developing with GWT here:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_SOP
The simple answer is: No, that's something that is disallowed for security reasons.
However, it should be possible to work around this limitation with all kinds of techniques (proxy servers, Yahoo Pipes, etc). As I'm no AJAX expert, I will leave the explanation of those to others.
Related
I have a long time setup which is capturing and decrypting HTTPS using Fiddler Proxy, I use my jailbroken phone so I can go around certificate pinning also and run it thru this proxy to capture traffic and analyze request/responses for different apps. I love Fiddler because it allows me to modify content on the fly at will to find issues. Today I ran into an app that is not behaving nicely and after some hours of research it seems my issue is because the app is using HTTP/3 and I haven't been able to make it work. Am I just barking at the wrong tree here? Is it even possible to capture such traffic with Fiddler Proxy? any alternatives with same like features that I could use? I'm not expert on protocols and certificates, etc. so please bear with me on the question :-). Thanks to any gurus out there that can help!
No, it's not possible.
As of right now, AFAIK there are no HTTP debugging proxies that support HTTP/3. For Fiddler specifically, they only shipped HTTP/2 support a few months ago (Jan 2022, 7 years after HTTP/2 was standardized) and only in Fiddler Everywhere. There's no mention of any timeline for shipping it in Fiddler Classic I can see, maybe never.
I can't speak for the Fiddler team's reasons, but I also maintain a debugging proxy and the general problem is that most languages don't yet have stable libraries available to easily handle HTTP/3, which makes it very difficult to support. There's some background on the causes of this here: https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/. There are some experimental implementations available now, but in most cases nothing that's easy to integrate and reliable, unlike HTTP and HTTP/2 (normally provided as part of programming languages' core libraries, often with many battle-tested userspace implementations available too).
From the HTTP/2 approach, I would guess that HTTP/3 support in Fiddler is a couple of years away at least and will only be coming to Fiddler Everywhere, not to Fiddler Classic (but I don't know for sure - you'd have to ask them).
In the meantime, the best workaround available is to block HTTP/3 traffic entirely. Well-behaved clients should fallback to HTTP/1 or 2 automatically. Blocking all UDP packets on port 443 using a firewall will generally be sufficient (it can be used on other ports, but I've never seen it in practice).
after reading all the threads on stackoverflow and other platforms, I still wasn't able to find an answer, which satisfies me.
The task:
I want to create a single page application (SPA) which receives data from a REST API. In this SPA, NO authentication should be used. It's a public site.
But the REST API should only be accessible from people who loaded the SPA from my webserver.
I assume this is only solvable with something on server side like sessions, cookies etc. - otherwise I'm open for your suggestions, solutions etc.
Thx in advance!
There's no reasonably easy way to do this. You can easily prevent other domains (in browsers) from accessing a an API on your domain (via CORS), but it's significantly harder to prevent scripts from doing this.
The issue lies in 'how do you detect legit browser traffic from a script'. It turns out that this is not easy. You could try to detect 'unusual behavior' as much as possible (for example a large amount of requests in a short time), but this doesn't stop clients that are slower.
Ultimately if people want your data, they will find some way around whatever restrictions you come up with. You should reevaluate this and use one of the following options:
Don't do an SPA and API. Although one could wonder, if the data exists in HTML it can still be crawled.
Add authentication. But obviously this won't help you in any way if anyone can authenticate.
Re-evaluate why you have this restriction. What are you worried about? If you're worried about people taking your data and using it elsewhere, how does only showing it in a browser from 1 domain help with that? If you're worried about copyright theft, why not use a legal approach to this?
I've seen a lot of these types of questions, but in my opinion I haven't yet seen one that has a legitimate good reason to want this. But, maybe you're the first.
I believe I answered my question myself on a comment 30 minutes ago... I think with captcha I'm able to secure the REST API against unwanted access to my REST API
I need to develop REST server strictly accrding to jsonapi.org specification and I'm not sure if there is some complex solution or even if it's easy to develop such thing.
I've found sails-hook-jsonapi, but it looks unmaintained for some time.
I'm new to Sails and not aware of all it's features and would appreciate any help, I may missed something obvious.
I have needed this too. There is not anything that works yet with Sails. sails-hook-jsonapi does not work correctly. I Forked that code and am maintaining my own version of it but there are still significant attribute serialization issues with multiple records. However, it does work at a basic level. I am also working on a new project sails-generate-jsonapi-blueprints but it is not nearly ready yet.
Sails is great but can ba a royal PIA. The guys maintaining Sails have had many requests for jsoanapi.org support but I do not believe that will happen anytime in the near future. If you REALLY must have JSONapi.org format I would suggest Loopback or some other API that already has support for it out of the box.
Actually, I take part of that back. sails-hook-jsonapi is working. I made a little change in the fork I maintain. https://github.com/NikkiDreams/sails-hook-jsonapi. Ian is maintaining the original project fork too I believe. https://github.com/IanVS/sails-hook-jsonapi
So the catch about the hook is that it hijacks every single request sent to responses/ok.js If you need something like an Authorizer that does not need jsonapi create a variant of ok.js that simply does a res.json(data) without the jsonapi-serializer being called when serializing the response.
sails-hook-jsonapi will serialize most of your data to your needs. But it still has a few limitations. Depending on the complexity of your queries these may not be an issue.
TODOs: Included request parameter handling (400 response if present)
Links
Top-level "self" links
Top-level "related" links
Resource-level "self" links
Related resource relationship links
Metadata links
Pagination
Formatting
Non-dasherized attributes
Sparse fieldsets
Long story short - there is no way to do it out of the box with little time investment. At least for now.
But sails-hook-jsonapi looks like good starting point, repository seems to be active now.
I've done project prototype on loopback.io framework, because I was in hurry and loopback had better jsonapi support.
I am new to Chrome App development. I was going to create a simple RSS reader as a helloworld project, but now, after reading docs, I am not sure that this is possible. The problem is, by the Content Security Policy for Chrome Apps it is forbidden to use domain in url_handlers without proving that this is your domain.
It makes retrieving RSS from sites impossible.
But there are references to some sandbox technology in the docs, and Chrome Apps can use low-level sockets. Can I somehow use it to get RSS from any site?
This question is difficult to answer because its topic is so broad.
But to answer if it's possible. Yes it is possible. You'll see that there are already RSS reader applications out there, go and check the webstore and even "reverse engineer" them to study it up if you want.
I also did some RSS reader for a few clients before.
I hope I can give you sample codes to you now but its better if you start looking into main documentation and sample apps.
You should read on XHR to access pages
https://developer.chrome.com/extensions/xhr
You may encounter a lot issues in tackling this project.
You need to consider that websites may load slow and your app should provide some UI for loading and some timeout to give up after a few seconds.
Webpages will redirect, so you should handle if you are going to follow it or not
Sometimes link is 404, or sometimes its not XML
You need to cache things, you may need servers help for this
It's a tough project to do but don't get discouraged.
It is still a fun and challenging one and you should go for it still!
Have fun coding!
Does anyone else find that the documentation of a lot of payment processors have poor or incomplete documentation as to how to use their API? Or it's just plain confusing?
Recently I have setup both PayPal and Beanstream and found that both are either confusing or don't include full documentation.
For example, in the BeanStream documentation, they say they will return a "message_id", which is great, but no where do they tell you what the different id's mean. It also comes with some text, so you can start creating a list, but there is no way to check to ensure you get either a valid one or the one that means it was successful.
Has anyone had this experience?
Edit: I will agree that when you email them they are helpful, but unfortunately most of them are only open normal business hours for general tech support (other than emergency) which isn't always useful as that isn't when it seems like I do my integration.
well, this isn't really specific to payment processor documentation, in that, all things being equal, well documented APIs will help encourage development. for what it's worth, i've worked with paypal, authorize.net, ups, and usps APIs, and didn't find them overtly confusing (not implying that they were a particular joy to get through).
that being said, i wish more documentation was like PHP's. despite it being such a scattered language, the documentation is really quite good.
Having worked with a lot of APIs, not only for payment processors but for lots of other ecommerce related web services, I have to say to that while the docs can be less than stellar, they usually aren't that bad, and if you send them an email or give them a call, they will usually be pretty helpful.
I have found the documentation and code examples from Authorize.net and Nova's ViaKlix very helpful. I stay away from PayPal.
This may not be much help to you, but as you get more an more experienced w/in particular domain the interfaces get easier. By weird twist of world, I've coded a whole bunch of credit card interfaces, and once you kind of get the lingo they all work the same.
The only other suggestion I would offer is to avail yourself of support resources in addition too the documentation provided. We recently worked with a relatively well known payment gateway, and while their documentation completely sucked (by their own admission as well), the support staff was incredibly knowledgable and more than willing to help out/explain.
I've used Realex and PayPal. Realex documentation is fine. Clear and straightforward. PayPal's is absolutely eye-bleedingly horrible. And I'm the kind of weirdo who enjoys reading documentation so much I've been known to read it for fun (I've read through the entire OpenID specificiation, even though I have no immediate plans to use it).
I've only worked with PayPal, but the simple version (where you just set up an HTML form on your web page and submit it with the PayPal button) is super-easy to work with. And if you're looking for near real-time payment feedback, I always found it easier to just write a program to check my PayPal email account periodically, and parse payment details from the body of the email itself.
I've had to use Authorize.net for several sites and the supplied documentation is 'just ok' assuming you are working in the somewhat limited technology sets that they supply sample code for. It was a breeze to get it up and running with PHP but considerably lacking when trying to pull off the same thing in ColdFusion.
Several other sites done via PayPal which IMO was a much better experience.
PayPal is a nightmare when it comes to setting up and testing the test account (Sandbox).
Re: Beanstream you have to login then you'll see the documentation link on the left hand side.
The design is so '90s and they recommend using IE.
Re: Paypal I adapted this code from http://www.php-suit.com/paypal for my Zend Framework project.
Note: you've got to have ssl:// socket transport wrapper registered otherwise (visible in phpinfo()) you'll have to tweak the code to use curl.
Here is how to get the code using SVN
svn checkout http://paypalphp.googlecode.com/svn/trunk/ paypalphp-read-only