I have a simple html page served from my local machine by an app running on port 8000, using the domain appdev.my_company.com.
The same app serves an API from the domain appcenter.my_company.com.
I have an endpoint in said API which sets a session cookie header that looks like this:
Set-Cookie:gac_3_6e...="VC1_69...=="; Domain=.my_company.com; Path=/
I made an ajax request to said endpoint, from the static page, hoping that the cookie would be set since the domain is the same (only the subdomain differs):
/* In http://appdev.my_company.com:8000 */
$.ajax({
url: "http://appcenter.my_company.com:8000/login/",
method: 'POST',
data: JSON.stringify(data),
success: function(){
console.log("logged in");
},
headers: {
"Content-Type": "application/json"
}
});
But it doesn't.
The cookie needs to be associated in the browser window with the current domain, because we need to reload a plugin that picks up this cookie (the cookie comes from a thrid party server).
How can I get this cookie to be registered in the browser? If I look into the resources tab of the web console, no cookie shows up.
I took a look at domain matching of the RFC6265, and it appears this should work.
What can be wrong in this case?
Please checkout CORS. This is the exact problem they try to solve. The only other way (to my knowledge) is to proxy the requests to the other source via your server.
Related
I have been trying to set a cookie in the browser and have failed. I cannot understand the reason, the cookie is not stored in the browser.
I have a setup at my local machine, where I am trying this. So the server and client both are at localhost but working on different ports. Here is the request that I make:
axios.post('http://127.0.0.1:3001/server/demo', {
lang: this.state.language,
url: this.state.url
}).then(res => {
// do other stuff ;
});
and this is the response that I get back from the server, which has the cookie header
As you see, the server wants the browser to set three cookies namely demo, url and lang. But none is being setup. What is exactly happening? What else is required here?
I have just followed the steps which were given in the Jenkins website. Now I can login into Jenkins using http://localhost:8080
When I use http://localhost:8080/api/json?pretty=true I can get JSON response from my localhost server. But when I try to get the data to a html page i.e., when I use url http://localhost:1234/foldername/file.html I'm unable to get the data using AJAX call. Below is the code I'm using for AJAX Call
$.ajax({
type: 'GET',
url: 'http://localhost:8080/api/json?pretty=true',
dataType: 'json',
//whatever you need
beforeSend: function (xhr) {
xhr.setRequestHeader('Authorization', make_base_auth('admin', 'admin'));
},
success: function (data){
alert(data);
}
});
function make_base_auth(user, password) {
var tok = user + ':' + password;
var hash = btoa(tok);
return 'Basic ' + hash;
}
I'm getting an authentication error.
From my understanding of the documentation, Jenkins recommends using your user's API key provided via HTTP Basic Authentication, not its password.
Modern jQuery (1.5 or later) also has added a headers field to the options for jQuery.ajax()
headers: {'Authorization': 'Basic ' + btoa('username:apitoken')}
However, what you describe here should do fine without these suggestions.
My assumption is that you are running into the Same-origin policy since your client is based in a browser document, from a different origin (different port) than your Jenkins server runs on. You will need to add CORS headers on your Jenkins server allowing your page's domain access to Jenkins resources, or have both Jekins API + your client page hosted from a single origin.
For your example here, you could use the CORS Filter Plugin and would need to add headers at least as permissive as follows:
Access-Control-Allow-Origins: http://localhost:1234
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: Authorization
In production, you could either use a single origin, or update the list of origins to include wherever your dashboard lives in production, or if you're confident about Same-origin problems, * as a wildcard for any origin.
I am working on a simple website using jwt. (node.js, koa.js)
Most example codes including expressjs, I cannot find the client-side example
about how to deal with jwt sent from a server.
Only one example (https://github.com/auth0-blog/cookie-jwt-auth) showed me that
[index.html]
... script src="app.js...
[app.js]
$.ajax({
type: 'POST',
url: 'http://localhost:3001/secured/authorize-cookie',
data: {
token: token
},
headers: {
'Authorization' : 'Bearer ' + token
}
After I read this example, I felt that I should have some scripts for users to send an authorization header with jwt. Is it right?
Or are there some front-end frameworks that deal with authorization header?
Thank you for reading newbie'q question.
Yes, you will need to define a mechanism for sending the user's JWT back to the server. It's up to you to decide where the JWT will live in the request -- the most common places are in the Authorization header, or by setting a cookie on the browser (which will be sent along with every HTTP request). You should also consider whether you want the JWT to persist across sessions / page reloads (using for example document.cookie or localStorage).
If you choose not to use the cookie approach, you can configure all $.ajax requests to set your Authorization header "pre-flight" using $.ajaxSetup({...}) (but this is a bit of a sledge-hammer approach). Manually setting the Authorization header on each individual $.ajax request, as you've demonstrated above, is a good option too.
If you want to skip headers all together, you can send the JWT inside the body of your request (as JSON, for example).
I have observed a scenario where a HEAD request made from a website I'm looking at in Chrome returns a session cookie, but the identical request, with identical cookies, headers, etc. made from Java code or Postman does not.
The call is coming from this JS: $.ajax({ url: myUrl, type: "HEAD", crossDomain: true, cache: false }). Due to the latter two flags, the url looks like https://myUrl?_=1433456890.
From a browser, observing from the console, the request goes out and a session ID that looks like it comes from ASP.net is returned as a Set-Cookie response header.
When I cut and paste all cookies, headers -- including User-Agent -- and the timestamped URL from the request into some other tool, I get a login failed redirect. I've tried incrementing the timestamp in various ways to no avail.
Is there any client- or server-side way to distinguish these two cases?
Is there something about that particular ajax/HTTP call that means it can't be reproduced by an arbitrary client with the appropriate session cookies?
i want to get the part of the different website page to my website content.
i have tried to do that with sending an ajax request to that webpage , but getting an cross domain access error
have any idea how to do that?
for example, i want to get this part only http://gyazo.com/600ee9facec408dd56a69c907293ebed from this website http://www.simbagames.com/en/aboutus.aspx
to my existing webpage, and put that content in my webpage content part
this is how i was tring to do that
jQuery.ajax({
type:'POST',
url: link,
crossDomain: true,
dataType: "html", // this is important
headers: { 'Access-Control-Allow-Origin': '*' },
success: function (data) {
console.log(data);
}
})
No need iframes
is that possible?
You need to add a header to response in aboutus.aspx. Or like Kasyx says, give up javascript and get with cUrl
"Access-Control-Allow-Origin: *"
Actually you cant because in addition by setting "Access-Control-Allow-Origin: *"
A server supporting CORS must respond to requests with several access control headers:
Access-Control-Allow-Origin: "*"
By default, CORS requests are not made with cookies. If the server includes this header, then we can send cookies along with our request by setting the withCredentials option to true.
Access-Control-Allow-Credentials (optional)
If we set the withCredentials option in our request to true, but the server does not respond with this header, then the request will fail and vice versa.
if server not responding you with the Access-Control-Allow-Origin: "*" then you cant fetch data
more about that