The first answer in this question: Session is lost and created as new in every servlet request is valid, however users in an intranet are very familiar no to type the whole domain in the URL. It will be very useful to configure the browser so they accept the URL without the domain and still keep the session.
According to this article: Cookie attributes- Domain and Path, you can know that the Domain attribute defines the scope of the cookie. It lets the browser know which website the cookie belongs to. If the server does not specify the domain of the cookie, it will default to the domain of the requested resource.
Therefore, I think your requirement cannot be implemented.
The decision was not to the browser, but to the Web.config file in the ASP.NET application. For a different issue we had to add the text cookieSameSite="None" to the SessionState tab in Web.config file on May 2020. Time came and apparently a new update of the browsers caused the application lost the session because it did not create the cookie with SessionID as ASP.NET need, unless we specify the whole domain in the URL.
That said we have 2 solutions: Remove the cookieSameSite="None" from Web.Config file or Type the whole domain in the address of the application.
From the 2 solutions the first one was not possible in our case, because the ASP.NET app is inside an iframe tab and without cookieSameSite="None" it does not keep the session, so we included the whole domain name inside the html page using iframe as src="myServer.MyDomain/MyApp/"
Related
I am trying to rename a file when downloading it from <a> tag.
Here a simple example:
Download Stackoverflow Logo
As you can see, it never downloads the file with stackoverflow.png name, it does with default name though.
Nevertheless, if I download the image and tried to do the same with a local route, it renames the file properly.
Another example:
Download Stackoverflow Logo
The example above works properly.
Why download html attribute only works using local routes?
Thanks in advance!
The attribute download works only for same origin URLs.
By the way, you really should learn to use proper terminology, or else people won't understand you:
<a href="https://i.stack.imgur.com/440u9.png" download="stackoverflow.png"> is a tag, specifically, an opening tag;
download is an attribute;
stackoverflow.png is the value of the attribute;
https://i.stack.imgur.com/440u9.png is a URL, sometimes called an URI or an address.
The entire construction Download Stackoverflow Logo is an element.
A "route" is something else entirely, and has no relationship with HTML.
I couldn't find any info of it, but seems like external resources aren't allowed renaming.
Have a look here, there's an example linking to google image and that doesn't work either - seems like the specs have changed along the way.
This is a security measure applied to cross-origin download requests where the server hosting the download does not use HTTP headers to explicitly mark the file as being for download.
From the HTML specification:
If the algorithm reaches this step, then a download was begun from a
different origin than the resource being downloaded, and the origin
did not mark the file as suitable for downloading, and the download
was not initiated by the user. This could be because a download
attribute was used to trigger the download, or because the resource in
question is not of a type that the user agent supports.
This could be dangerous, because, for instance, a hostile server could
be trying to get a user to unknowingly download private information
and then re-upload it to the hostile server, by tricking the user into
thinking the data is from the hostile server.
Thus, it is in the user's interests that the user be somehow notified
that the resource in question comes from quite a different source, and
to prevent confusion, any suggested file name from the potentially
hostile interface origin should be ignored.
I'm currently creating pdf documents server side with wkhtmlpdf and nodejs. The client side sends the html to be rendered (which may include img tags with a source). When the user is previewing the html in the browser the images they uploaded to their account show fine because the user is authenticated via the browser and the node route can simply look up the image based on the user id (saved to session) and image id (passed in each image request).
The issue is when the images are attempting to be rendered in wkhtmltopdf webkit the renderer is not authenticated when it makes the request for images via node's exec of wkhtmltopdf in a separate process. A request to something like GET /user/images/<imageId> will fail due to the session not being set when the request is made inside the headless wkhtmltopdf renderer.
Is there a way to pass authentication via some wkhtmltopdf option or possibly a different way of authentication for images? The only restriction is not making images public.
I asked a similar question a while back that might help you:
Generate PDF Behind Authentication Wall
WKHTMLTOPDF has --cookie-jar which should get you what you need. Note that it didn't for me, and I wound up answering my own question with an alternate solution. In a nutshell, I wound up accessing the page via CURL - much more flexible - then writing a temporary that I converted to PDF, then deleted the temporary file.
A little round-a-bout, but it got the job done.
To implement authentication I allowed a cookie id flag ( with connect the key defaults to connect.sid ) as a query option in my image routes. The only "gotcha" is since images are requested from the server's perspective, you must ensure all your image paths are absolute domain paths rather than relative to your application ( unless those two are the same of course).
Steps for Expressjs:
Setup the id flag middleware which checks for say sid in the query via req.query (eg ?id=abc123 where abc123 is the req.cookies['connect.sid'], or req.signedCookies['connect.sid'] if your using a secret as you probably should )You may need to ensure the query middleware is setup first.
Ensure the req.headers contains this session id key and value prior to the cookie parser so the session is properly setup (eg if a cookie exists append a new one or if one does add it as the first req.headers.cookie = 'connect.sid=abc123;')
Ensure all image paths contain the full url (eg https://www.yourdomain.com/images/imageId?id=abc123)
Some extra tid bits: The image source replacement should probably happen at the server level to ensure the user does not copy/paste the image url with the session id and say email it to a friend which obviously leaves the door open for account hijacking.
I'm thinking about this question for a long time. It is a big question, since it almost covers all corners related to web developing.
In my understanding, the process should be like:
enter the url to the address bar
a request will be sent to the DNS server based on your network configuration
DNS will route you to the real IP of the domain name
a request(with complete Http header) will be sent to the server(with 3's IP to identify)'s 80 port(suppose we don't specify another port)
server will search the listening ports and forward the request to the app which is listening to 80 port(let's say nginx here) or to another server(then 3's server will be like a load balancer)
nginx will try to match the url to its configuration and serve as an static page directly, or invoke the corresponding script intepreter(e.g PHP/Python) or other app to get the dynamic content(with DB query, or other logics)
a html will be sent back to browser with a complete Http response header
browser will parse the DOM of html using its parser
external resources(JS/CSS/images/flash/videos..) will be requested in sequence(or not?)
for JS, it will be executed by JS engine
for CSS, it will be rendered by CSS engine and HTML's display will be adjusted based on the CSS(also in sequence or not?)
if there's an iframe in the DOM, then a separate same process will be executed from step 1-12
The above is my understanding, but I don't know whether it's correct or not? How much precise? Did I miss something?
If it's correct(or almost correct), I hope:
Make the step's description more precise in your words, or write your steps if there is a big change
Make a deep explanation for each step which you are most familiar with.
One answer per step. Others can make supplement in each answer's comment.
And I hope this thread can help all web developers to have a better understanding about what we do everyday.
And I will update this question based on the answers.
Thanks.
As you say this is a broad question where it's possible to go into great detail on a number of topics. There's nothing wrong with the sequence you described, but you're leaving out a lot of detail. To mention a few:
The DNS layer can help direct clients to different servers based on geographical location to help with load balancing and latency minimization, and one server can respond to requests from many different DNS names.
A browser can make different types of requests (GET, POST, HEAD, etc), and usually includes several different headers including cookies, browser capabilities, language preferences, etc.
Most browsers usually maintain a cache in order to avoid downloading stuff many times, and use various techniques to determine whether the cached version of a file is valid.
In modern webpages there's often complex interaction between many different kinds of files (HTML, CSS, images, JavaScript, video, Flash, ...), and web developers often need detailed knowledge of differences among browsers in order to keep their pages working for everyone
Each of these topics, and many more, could be discussed at length. Perhaps it's more practical to ask more specific questions about the topics you're interested in?
You type maps.google.com(Uniform Resource Locator) into the address bar of your browser and press enter.
Every URL has a unique IP address associated with it. The mapping is stored in Name Servers and this procedure is called Domain Name System.
The browser checks its cache to find the IP Address for the URL.
If it doesn't find it, it checks its OS to find the IP address (gethostname);
It then Checks the router's cache.
It then checks the ISP's cache. If it is not available there the ISP makes a recursive request to different name servers.
It Checks the com name server (we have many name servers such as 'in', 'mil', 'us' etc) and it will redirect to google.com
google.com name server will find the matching IP address for maps.google.com in its’ DNS records and return it to your DNS recursor which will send it back to your browser.
Browser initiates a TCP connection with the server.It uses a three way handshake
Client machine sends a SYN packet to the server over the internet asking if it is open for new connections.
If the server has open ports that can accept and initiate new connections, it’ll respond with an ACKnowledgment of the SYN packet using a SYN/ACK packet.
The client will receive the SYN/ACK packet from the server and will acknowledge it by sending an ACK packet.
Then a TCP connection is established for data transmission!
The browser will send a GET request asking for maps.google.com web page. If you’re entering credentials or submitting a form this could be a POST request.
The server sends the response.
Once the server supplies the resources (HTML, CSS, JS, images, etc.) to the browser it undergoes the below process:
Parsing - HTML, CSS, JS
Rendering - Construct DOM Tree → Render Tree → Layout of Render Tree → Painting the render tree
The rendering engine starts getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.
A DOM tree is built out of the broken response.
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files).
At this stage the browser marks the document as interactive and starts parsing scripts that are in "deferred" mode: those that should be executed after the document is parsed. The document state is set to "complete" and a "load" event is fired.
Each CSS file is parsed into a StyleSheet object, where each object contains CSS rules with selectors and objects corresponding CSS grammar. The tree built is called CSSCOM.
On top of DOM and CSSOM, a rendering tree is created, which is a set of objects to be rendered. Each of the rendering objects contains its corresponding DOM object (or a text block) plus the calculated styles. In other words, the render tree describes the visual representation of a DOM.
After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen.
The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.
Repaint: When changing element styles which don't affect the element's position on a page (such as background-color, border-color, visibility), the browser just repaints the element again with the new styles applied (that means a "repaint" or "restyle" is happening).
Reflow: When the changes affect document contents or structure, or element position, a reflow (or relayout) happens.
i was also searching for the same thing and found this awesome detailed answer being built collaboratively at github
I can describe one point here -
Determining which file/resource to execute, which language interpreter to load.
Pardon me if I am wrong in using interpreter here. There may be other mistakes in my answer, I will try to correct them later and include proper technical terms for things.
When the web server (e.g. apache) has received the URI it checks if there is any existing rewrite rule matching it. In that case the rewritten URI is taken. In either case, if there is no file name to end the URI, the default file is loaded, which is generally index.html or index.php etc. According to the extension of the file name, the appropriate apache module for server-side programming language support is loaded, e.g. mod_php for PHP, mod_python in case of python. The appropriate server side language interpreter (considering interpreted languages like PHP) then prepares the final HTML or output in some other form for the web server which finally sends it as the HTTP response.
I hope above image help you to understand whole process.
Full article is here
I wan't developers who embed my webapp to be able to pass a param in the url like ?style=dark which will alter the css accordingly. Is there a better way to keep this setting as the user navigates than appending ?style=dark to all links?
I've considered cookies etc. but if one user is viewing two pages which embed my app with different themes then one will override the other.
I'm using Python/Django.
If you neither want to use Cookies nor Sessions and do not want to embed it into URLs, the only alternatives which comes to my mind are:
First the most generic: Use a dummy domain in front. Instead of www.example.com use h**p://THEME.example.com/PATH. This even works for HTTPS if you own a wildcard SSL for *.example.com.
A second variant would be to create a Basic-Auth-Handler which uses the Theme as the username with a dummy password. The URL then can look like:
h**p://THEME#www.example.com/PATH
However I am NOT sure what happens if a user connects to the same site with two different themes in the Basic-Auth-case. Also it is somewhat tricky to make the site available for search engines if it is behind an authentication handler. This is because you MUST have an auth-handler today to circumvent the Anti-Phishing-protection in modern browsers.
Note that with both methods you can only have one parameter easily. The password does not count and there are browsers out there which do not accept a wildcard SSL cert *.example.com for PARAM1.PARAM2.example.com.
I'm not exactly sure, but anyway you would have to pass this variable to your site. With that I mean, that there is no difference if you add ?style=dark to your href's, or rel="dark" to your <a>'s for use with javascript. keep in mind that it's just an example
Ofcourse you can always work on that AI to predict what the user wanted at the specific moment. hehe
I'm sure you can use a Session for this kind of thing, not? The first time the values are provided via the Querystring you add them to the Session and then retrieve them from the session in the future.
We have 2 different websites. One is xy.com another is xyz.com. The domain xyz.com is redirected to a folder on xy.com\one
This works fine. Now we want a particular link to be opened (for example, www.xyz.com\abc.html). I am placing this file in xy.com\one\abc.html. But when I enter this url, it takes me to home page, instead of abc.html. Though I can open abc.html, by entering www.xy.com\one\abc.html.
I need to open this file, from link, www.xyz.com\abc.html. How to accomplish this??
Regards,
Rahul Jain
I think the problem is your slashes are reversed. Did you keep your url's near a strong magnet?
If you are using apache you might want to have a look at mod_rewrite. There are similar methods available for other servers.
Would be good to know which environment you are using (web server and server side language) and if you are applying the re-direct rules in a programmatic way or via server configuration.
To give a serious reply, there could be several things wrong in the redirect.
You have to setup a redirect from the old domain to the new, by using a .htaccess on the old domain, changing the DNS records for the domain, or probably some other alternatives. Which of these have you used?
In case of the second option the receiving server (xy.com) has to accept the incoming domain (xyz.com). When I set my DNS records for a domain to go to a certain server, I have to actually setup the server to accept that domain, usually by "parking" it in Cpanel. Some hosts charge per parked domain, which is why they don't accept the incoming traffic automatically.
Depending on the method used, the receiving server has to be told what to do with the request.
So most importantly: HOW did you set up the redirect? Was it a DNS record? Was it a htaccess on the side of xy.com? Any other methods? (sorry, this isn't really an answer either but it was too long for the comments)