I have a situation, when I should to send a POST request to authenticate user, if it's succeed then server set a cookie and then we can get a protected page:
First request by Postman:
Second request (after first):
I need to implement it on web page. As I understand now, it's possible only via frames. How to do it? First request should be sent automatically after opening a page, so, user should open the page and see a protected page.
Cookie Authentication is you are trying to achieve?, here is are some links which will help to you with that.
https://dzone.com/articles/cookie-authentication-with-aspnet-core-20
As part of email signup process, I send a url in an email. The client should click it, my server applications sends a 303 response redirecting the client to the home page and the browser should open the home page. But this isn't happening. I am unable to debug whether this is a browser issue or web-server issue.
in this pic, you could see that on clicking the url, a request GET is sent and 303 is received
Here, I don't see any request going out (I see request headers but I am not convinced that the request was sent). In the timing tab, it looks as if the request is stalled
It seems the issue was the way I was redirecting. In of redirecting using absolute path Redirect("http://localhost:9000/home"), I wasn't using http i.e. Redirect("localhost:9000/home") which made the path relative. The initial request was http://localhost:9000/ws/users/signup/ and the new request after redirect became http://localhost:9000/ws/users/signup/localhost:9000/home which probably messed up something in the browser.
Suppose I make a webpage that includes
<iframe src="http://google.com"/>
and a user browses through that iframe. Does Google see the request made from the server I'm hosting my site on, or from the user's router?
You do NOT load content of iframe source from your server. You just pass that code to the user browser then everything happens on client side. Therefore google will see client ip address and etc.
When one website is called through another domain whether iframe or not, browsers send current domain name to the next target (google.com in your case) with HTTP Referrer data. This is the only way of google.com to understand where the client request google from.
Details : What is the HTTP Referer if the link is clicked in an <iframe>?
I have a page on domain A which loads a webworker script from domain B. The webworker is fetching some PNGs from doman A's server.
In Firefox, the request to get the PNGs contains the cookie for my site (domain A).
In Chrome, it does not include the cookie for my site, and so fails because the request must be coming from a logged in user (which requires the session cookie to be sent in the request).
Which browser is behaving correctly, and can I do anything to make Chrome send the cookie for the current domain from within a webworker?
UPDATE:
I pulled all the files from domain B and hosted them on my server at domain A, so the webworker file is now on the same domain as the site itself, but Chrome still does not send the session cookie with the requests from the web worker.
With regards to the first problem, it looks like the Firefox is incorrect, you shouldn't be able to instantiate a Worker on another domain to quote the spec:
"If the scheme component of worker URL is not "data", and the origin
of worker URL is not the same as the origin specified by the incumbent
settings object, then throw a SecurityError exception and abort these
steps."
With regards to Chrome the Workers run in a separate they work for me and without seeing more code it's hard to answer. But if you visit this demo and break before the postMessage to the worker set document.cookie='test=1' you will see that when the request goes out from the worker it is set.
I don't understand: how are webserver and trackers like Google Analytics able to track referrals?
Is it part of HTTP?
Is it some (un)specified behavior of the browsers?
Apparently every time you click on a link on a web page, the original web page is passed along the request.
What is the exact mechanism behind that? Is it specified by some spec?
I've read a few docs and I've played with my own Tomcat server and my own Google Analytics account, but I don't understand how the "magic" happens.
Bonus (totally related) question: if, on my own website (served by Tomcat), I put a link to another site, does the other site see my website as the "referrer" without me doing anything special in Tomcat?
Referer (misspelled in the spec) is an HTTP header. It's a standard header that all major HTTP clients support (though some proxy servers and firewalls can be configured to strip it or mangle it). When you click on a link, your browser sends an HTTP request that contains the page being requested and the page on which the link was found, among other things.
Since this is a client/request header, the server is irrelevant, and yes, clicking a link on a page hosted on your own server would result in that page's URL being sent to the other site's server, though your server may not necessarily be accessible from that other site, depending on your network configuration.
One detail to add to what's already been said about how browsers send it: HTTPS changes the behavior a bit. I am not aware if it's in any spec, but if you jump from HTTPS to HTTP, and if you stay on the same domain or go to different domains, then sometimes the referrer is not sent. I don't know the exact rules, but I've observed this in the wild. If there's some spec or description about this, it would be great.
EDIT: ok, the RFC says plainly:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
So, if you go from HTTPS page to a HTTP link, referrer info is not sent.
From: http://en.wikipedia.org/wiki/HTTP_referrer
The referrer field is an optional part
of the HTTP request sent by the
browser program to the web server.
From RFC 2616:
The Referer[sic] request-header field
allows the client to specify, for
the server's benefit, the address
(URI) of the resource from which
the Request-URI was obtained (the
"referrer", although the header
field is misspelled.)
If you request a web page using a browser, your browser will sent the HTTP Referer header along with the request.
Your browser passes referrer with each page request.
It seems unusual that JavaScript has access to this as well, but it does.
Yes, the browser sends the previous page in the HTTP headers. This is defined in the HTTP/1.1 spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36
The answer to your question is yes, as the browser sends the referer.
"The referrer field is an optional part of the HTTP request sent by the browser program to the web server."
http://en.wikipedia.org/wiki/HTTP_referrer
When you click on a link the browser adds a Referer header to the request. It is part of HTTP. You can read more about it here.