I write a bunch of scripts in javascript and want to switch to dart or at least start using it. I do have one question though: i know js doesn't support x-domain requests in the browser, but what about running a dart application/script from the server, is it still the same? can this even be done?
basically, since i have no access to the web server to which i query, cross domain ability is a big necessity.
It sounds like you might be asking about writing a server side command line script which can make requests to an HTTP server. Though the wording of question isn't totally clear to me. (The answers above are about browser based Dart scripts.)
This is possible with Dart. There are no cross origin restrictions in this case.
See the HttpClient class.
Or you can use the http package on pub.
I recommend using the http package, as it provides a simpler high-level interface.
Here is an example using the http package:
import 'dart:io';
import 'package:http/http.dart' as http;
main() {
http.read("http://google.com").then((content) {
print(content);
});
}
You'll need to update your pubspec.yaml file to add the following dependencies:
name: Http Example
dependencies:
http: any
pathos: any
(Actually, you should only need to include http, but I think the http package is missing the pathos dependency in it's pubspec.yaml file.)
I couldn't find the pretty documentation for http, but there is some doc comments in the source file.
Cross domain security is built into the browser, so is neither a feature of Dart or JavaScript.
Useful for testing: you can pass flags into chrome that will disable this security feature. See here: http://joshuamcginnis.com/2011/02/28/how-to-disable-same-origin-policy-in-chrome/
If you want to do a GET request, then you can use Dart JavaScript interop, see this section in this article: http://www.dartlang.org/articles/json-web-service/#note-on-cors
If you want to POST requests on the other hand, you'll run into problems unless the target server supports CORS. More details here: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
Edit: The correct approach would be to have your client-side code communicate with a server you own, and have that server communicate with the third-party server.
You can enable cross-origin requests on the server by setting the Access-Control-Allow-Origin header on the http response. The value is either * to allow any origin to access the resource, but it is definitely safer to specify valid origins.
Related
I am trying to migrate a legacy system to use artifactory. However I have two blockers:
the old scripts require PyPixmlrpc, which artifactory doesn't support
they also make use of upload_docs, not supported by artifactory's pypi implementation either
a smaller issue, the old scripts call register and they expect 200 instead of 204 http status code.
Would it be possible for me to write a plugin to implement this?
Looking at https://www.jfrog.com/confluence/display/RTF/User+Plugins I couldn't find a callback for when POST /api/pypi/<index-name> is requested.
If I can make
work for the methods we actually use, to just pretend it deployed docs and to respond with the correct status code I will be happy enough.
As you say, there is no plugin hook for the Pypi API endpoints. It would be possible to use the altResponse endpoint to customize artifact downloads, but then you would be restricted to GET requests with no request body, which is also not a good option for you.
I think the most viable approach would be to define a custom executions endpoint. With this, you can specify the acceptable method, read the body, and set your own response code and body. The main shortcoming with this is that you can't customize the path (it's always /api/plugins/execute/[execution_name]), but this can be worked around.
Execution endpoints can take params in the following form:
/api/plugins/execute/[execution_name]?params=[param_name]=[param_val]
Say your plugin takes a param path, which represents the API path your old scripts are going to call. Then you can set your base URL to /api/plugins/execute/[execution_name]?params=path=/, so that the API path is appended to the param. Alternatively, you can use nginx or another reverse proxy to rewrite the original API path to this form.
(Since you'll be using XML-RPC, I don't suppose you'll need to worry about any of this path stuff, but I'm including it anyway for completeness.)
Some issues with this approach:
Execution endpoints only allow String responses, so sending binary data in the response body might be finnicky. However, no such limitation exists with the request body.
If you need more than one request method, you'll need more than one execution endpoint. This means you'll need to use a reverse proxy to rewrite each method to a separate endpoint. Again, since XML-RPC just uses POST, this probably won't be an issue for you.
Execution endpoints can't customize response headers. Therefore, if your scripts expect a particular Content-Type or other header, you'll need to use a reverse proxy to insert it into the response.
I am creating a REST API in Go, and I want to build URLs to other resources in my replies.
Based on the http.Response I can get the Host and URL.
However, how would I go about getting the transport scheme used by the server? http or https?
I attemped to check if server.TLSConfig is nil and then assuming it is using http since it says this in the documentation for http.Server:
TLSConfig *tls.Config // optional TLS config, used by ListenAndServeTLS
But it turns out this exists even when I do not run the server with ListenAndServeTLS.
Or is this way of building my URLs the wrong way of doing things? Is there some other normal way of doing this?
My preferred solution when running http and https is just to run a simple listener on :80 that redirects all traffic to https. Then any real traffic can be assumed to be https.
Alternately I believe you can access a request's URL at req.URL.Scheme to see the protocol.
Or do you mean for the entire application? If you accept configuration to switch between http and https, then can't you look at that and see which they chose? I guess I'm missing some context maybe.
It is also common practice for apps to take a baseURL via flag or config to generate external urls with.
I know that HTTP is hyper text transfer protocol, and I know that's how (along with HTTPS) one accesses a website. However, what does just a // do? For instance, to access Google's copy of jQuery, one would use the url //ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js, as opposed to http://....
What exactly is the difference? What does just // indicate?
Thanks.
By saying on // it means use whatever protocol (IE: http vs https) your user is currently hittin for that resource.
So you don't have to worry about dealing with http: vs https: management yourself.
Avoiding potential browser security warnings. It would be good practice to stick with this approach.
For example: If your user is accessing http://yourdomain/ that script file would automatically be treated as http://ajax.googleapis.com/...
if your current request is http
//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
will be treated as
http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
if your current request is https
//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
will be treated as
https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
We have Jira 5.x running in the standalone variant (embedded tomcat). We'd like to prevent any request without a valid http basic header from reaching the Jira application. Or, in other words, force JIRA to use HTTP Basic authentication. Yes, I know that transmitting http basic credentials over the wire without tls isn't secure and stuff, but we don't have an SSL certificate anyway, so that doesn't matter (it doesn't make it worse than it actually is).
I read that Jira handles HTTP Basic Authentication headers if it gets them, and appending ?os_authType=basic to the URL makes Jira behave as we wish, but we'd like Jira to enforce HTTP Basic. We wouldn't care if we had some kind of "even-before-jira" login statically configured in tomcat as long as the jira application wouldn't be reachable from outside without it.
Is there a way to achieve this?
I tried adding:
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
to jira's web.xml but that didn't help.
I have some software which makes a request to a specific URL in internet and I want it to receive my custom response. Is there any software tool for that on Windows? Also it would be nice if I could map a regexp instead of specific URL
Found the solution myself:
Set the domain of the URL to point to 127.0.0.1 in windows hosts file
Install nginx and set it up to show your file for the request response to which you're willing to modify and proxy all other requests to the original server
You could consider writing a test and mocking out the http response with your custom response.
I could give an example using C# and rhino mocks but it's not clear which platform you are working with.
You can:
Try to enject your dll into the process and replace functions like (HttpSendRequest, HttpQueryInfo,...) with your oun versions.
Try to use something like WinPCap (http://www.winpcap.org/).
Fiddler (www.fiddler2.com) has an AutoResponder feature which does exactly that.