I am working on securing solr and one thing caught my thought is to disable stream sources completely by:-
Disable multipart uploads
Disable POST requests which are not having content-type header
Disallow stream.body parameter.
Keep the remote stream disabled.
I seek an advice is it a wise thing to do the above. If yes then how to disable multipart uploads in solr. After searching through google I did not get enough to get by. Rather thought to do the following
I wish the community to share the thoughts on how to achieve this.
I found the best way of doing it.
Use the Node based proxy.
https://github.com/dergachev/solr-security-proxy
Related
This may be the wrong way to phrase this, however I'll ask none the less.
Can I code a Firebase database to accept and parse SOAP protocol messages into my database?
I am new to databases in general, aside from sql, and am just trying to make sure I start off on the right footing.
I will be displaying my Firebase database entries to a webpage.
All SDKs and APIs to access the Firebase Database are documented here. At the moment that does not include a SOAP API.
It is unlikely that such an API will be added (definitely not in the near future). You could try searching if somebody has made a bridge, but I don't recall every hearing of one.
I have a requirement where our application based out of Camel can get huge payloads (50+mb) responses too.
We need a way to reject such huge responses. I couldn't find a built-in feature within Camel that enables this.
At this point, I am planning to build a custom throttler as I have exhausted with searching in web too for external custom Camel components that offers this feature.
Before re-inventing wheel, I thought if someone already encountered this scenario and has had a solution that can be shared with me.
Thanks in advance.
I think if you use a processor to simply get the size of the payload and set it on a property, you can then use that as a filter in your route.
Processer:
int payloadSize = exchange.getIn().getBody(byte[].class).length;
exchange.getIn().setHeader("payloadSize", payloadSize)
and then in your route:
.filter(header("payloadSize").isLessThan(50 * 1024 * 1024))
If enabling stream caching then it has a length method you can use to know the size of the payload, and then reject the message if its bigger than X.
Mind the throttler EIP pattern does not reject message, it only slows down messages. To reject a message use Content Based Router, Filter, etc.
You can also look at using interceptors and use a from and check the size and then if its to be rejected set some error code / error body, and then stop the routing.
http://camel.apache.org/stream-caching.html
http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/StreamCache.html
http://camel.apache.org/intercept
I need to send a multipart document to a server. IT seems however that the server expects the boundary to be a specific sequence "********". If I use multipart request, it seems to default to something else even when I add a request header.
That is indeed missing in the current version of Codename One (didn't expect people would need functionality like this).
We will add a setBoundary(String) method for the next update in 3 weeks or so.
in the official trigger.io docs there seems to be no provision for custom http headers when it comes to the forge.file module. I need this so I can download files behind an http authentication scheme. This seems like an easy thing to add, if support is not already there.
any workarounds? any chance of a quick fix in the next update? I know I could use forge.request instead, but I'd like to keep a local copy (saveURL).
thanks
Unfortunately the file module just uses simple "download url" methods rather than a full HTTP request library, which makes it a fairly big task to add support for custom headers.
I've added a task to our backlog for this, but I don't have a timeframe for it being added.
Currently on iOS you can do basic auth by using urls in the form http://user:password#url.com in case that helps.
Maybe to avoid this you can configure your server differently, or have a proxy server in front that allows you to pass authentication details as get parameters?
EDIT: Looks like this post is much ado about nothing, as the OPTIONS preflighting was introduced late last fall; my problems have been more user error than anything. See comments for more details (I'll leave it all here for documentation's sake). --jlm
It's a known issue that the Youtube API does not support the OPTIONS request method, so any web app that tries to do a Cross-Origin preflight will fail, even if (as is the case with the Youtube API) the actual CORS request would succeed. As we've been facing this issue yet again this week, we've come up with three workarounds; however, each has it's own plusses and minuses.
POSSIBLE WORKAROUND #1: Forget the preflight, and just make the simple cross-origin request.
Benefits -- A) it works. B) this is all the specification requires when doing most GET or POST requests.
Drawbacks -- A) The specification states that any PATCH, PUT, or DELETE requests, along with POST requests that use a content-type other than form-data, url-encoded, or text/plain, need to be preflighted. So while it would work, it would be breaking the spec (which we'd like to avoid if possible). B) Preflighting is also necessary when setting custom headers; so, for example, when I use AngularJS's $http method in the 1.0 branch, it sets a custom header and thus triggers preflighting of even GET requests. In this case, of course, I could write my own $http service or move to the 1.1 branch (as the problem would really be on Angluar's end).
POSSIBLE WORKAROUND #2: Use JSON-P
Benefits -- A) it works, too (in some cases, anyway). B) It's fairly simple to set up.
Drawbacks -- A) An older technology, and it isn't clear if the Youtube API will continue to support JSONP. B) Requires a callback. C) Is limited to GET requests only.
POSSIBLE WORKAROUND #3: Set up a server-side proxy on the same domain, use it to communicate with the Youtube API.
Benefits -- A) Avoids the need to do CORS requests at all, since the client works on the same origin and the server-side proxy has no need to preflight anything.
Drawbacks -- A) Can get complicated to set up, especially if trying to work with credentials (oAuth2 through a proxy can be quite the beast).
So that this post has an actual question (or several, actually)
What take do you have (for better for worse) on any or all of the workarounds above?
Has anyone implemented other solutions?
Is there any information as to if/when the Youtube servers might support the OPTIONS method?
Any and all comments are welcome -- and I apologize in advance if this isn't the best forum for such a question (although I'm hoping that by putting it here on Stack Overflow, it'll prove useful to others facing the same issue)
Youtube upload API(uploads.gdata.youtube.com) doesn't support CORS.
You may vote the issues here and here . There are also several forum posts about it. CORS is not working !
It seems Google is still working to fix it , though started working on it about an year ago so most likely the API will be deprecated before to have the issue fixed(as we already have a V3).
The only workaround is to use a proxy(which is not cool). Basically upload the video on your server and then send it to youtube.