Develop Reference

Setting cookie for the server's own domain

I work both on client and server. When developing, my client runs on http://localhost:3000/ while my server runs on https://local.somedomain.com. The server sends a cookie like
set-cookie: a=aB5Th....;Path=/;Expires=Sun, 02-Aug-2020 11:26:36 GMT;Max-Age=5184000
This cookie is needed for a download link looking like
https://local.somedomain.com/api/v2/ExportSomething.xlsx
however, it isn't there. As the server didn't specify a domain, it might make sense. OTOH, according to this answer, "You can't modify the cookies of one domain using a servlet or JavaScript hosted on another domain, for security reasons", and I don't want to set any cookie for any domain except the one the server runs on, so I'm asking why to specify anything when there's no choice?
Filtering "Has blocked cookies" in Chromium devtools shows nothing, which I'd interpret as "everything is fine, cookies came through". Am I wrong?
The strange thing is that it used to work one or two weeks ago, at least in Chromium (and I'm very sure about that as I worked a few hours on the export). Now it works in none of the four browsers I have tried. Any explanation?
Assuming it's necessary to specify the domain when setting the cookie, is this comment correct?
Boring details
every request sets the cookies in the same way
no requests beside the above download link use cookies
CORS is obviously needed and works and every request gets handled the same way
there are no other servers involved
Update
I've just tried cookie.setDomain("local.somedomain.com") and also this with a leading dot and it didn't help.
I also tried leaving out the Max-Age (which also removes Expires which was otherwise added automatically) and it didn't help either (someone claimed that only session cookies work on localhost).

Possible reasons for such behavior (that I can think of):
The browser settings reject all third-party cookies (if localhost receives a cookie from local.somedomain.com, that would be considered third-party)
A browser extension is blocking the cookie
The local.somedomain.com server response does not include the necessary CORS headers to allow localhost to receive the cookie. (Access-Control-Allow-Origin must be present and not set to '*', Access-Control-Allow-Credentials must be present and 'true')
Google is messing with you
That last point is actually not a joke, and most likely the cause here. Google has been tweaking the "SameSite" rules for cookies in Chromium, documented here: https://www.chromium.org/updates/same-site
An a related case on SO: Confusion regarding SameSite changes with Chrome

How to trace 'There was an internal error and internet explorer unable to print this document' in IE

We are getting 'There was an internal error and internet explorer unable to print this document' in IE at client place for a JSP webpage in our application.
Where to verify any logs related to the above error in IE at client's place.
Does this error can be traced using F12 developer tools or any other options to verify the error log.
We are not getting the error for IE in our environment.
Please help us regarding this.
Thanks in advance

When a page is not displayed as expected client side here is what can be done, from the simpler to more complex:
search the server logs for possible server side errors
try to look at the source code of the page (normally in the contextual menu obtained with a right click). It is what the browser has received and if no javascript was involved what it is trying to display. You can try to see whether it is what you wanted the server to send
try to look at the actual page content with the F12 developper tools. This is the current page after possible Javascript code has altered the original data
use a network analyzer like wireshark. This will show you the exact requests sent by the browser and the exact responses received from server
use the developper tools to trace all actions involved in the page, including the different requests necessary to download the different component of the pages, and all javascript actions.
It may be a rather broad answer but it is the best I can do with the informations given in the question.
And for the it happens on customer machine but not on my dev machine part, I have no more than the usual advices:
try to connect to your server through a raw internet access - for example with a smartphone as router
ask the client for the exact versions of the browser and host OS
ask him for possible plugins in the browser
ask him for possible filtering rules in his proxy - and also control the server proxy rules if any...
ask him for screen images of the error page, and of the source code of the page

SSL/TLS Protocol version in Javaee

Is there any way in Java EE to know what SSL/TLS protocol is being used for a secure connection?
Ideally I want the application to use TLS/1.2 for everything, but I know some browswers (ie 9 say) by default wont support that. If I configure my enviroment to only allow TLS/1.2 then IE 9 will go "ohh this website is down", if you then click help, advance it actually tells you "oh this might be that the settings in IE disable sensible encryption, you and do this to enable sensible encryption". (I am paraphrasing slightly).
Anyway the response is a cold, "website down", which is not true, its just IE does not wish to support sensible protocols. My preference would be to change the configuration to allow weaker protocols like TLS/1.0, my application can then detect that a weak protocol is being used and on every page there can be some sort of warning "you know this is not secure, click here for more information", ie a helpful message that confirms that the website is working, just their browser is insecure. I cant see any attributes that form part of HttpServletRequest that might give me this information or any other method that answers the question.
Any thoughts?

I'm not sure if you can get the TLS protocol compatibility upfront.
How about checking for browser and its version in the request.
If any of the browsers (like you had mentioned ie) are having issues with it, then send that Warning message of yours in the response along with the actual content.
You can get the browser info using:
String userAgent = request.getHeader("User-Agent");
Also, you could probably look up some answers for achieving this using javascript. As it resides at client end, it could be used to handle such scenario's.

Filtering URLs to allow only the ones that are publicly visible

Users in my app can send messages between them and they can embed images from public sites in the content. I'd like to download those images and store them in my own storage, so my app won't break when the images are deleted from the internet.
I'm corcened about the security implications.
What if the user sends a message with a img src that starts with http://localhost. I'll be requesting my own server.
What if the src is a private ip. I'll be connecting to servers in my private network.
What if the src is a host that resolves to 127.0.0.1.
And other nasty ideas I can't think of.
What can I do in order to check I'm downloading an image from a public server and not hitting my owns.
I'm using standard Java.

There are front end and backend solutions for this.
Simply prevent your app from accepting such links. Use patterns to ensure certain things are filtered, for example, localhost links or abusive links. Even if they are shortened. https://stackoverflow.com/a/8151742/2110818
Or configure your firewall to ensure that ports 80 and 443 are not accessible on the machine that has the apache server. There's plenty you can do.
Which server are you using or are going to use to host your server? For example, you can secure tomcat or other servers and prevent things from happening like here: https://www.mulesoft.com/tcat/tomcat-security
Also, one should try to prevent any kind of unvalidated redirect anyways even within their code. So, don't just focus on external threats, your own code could hurt you. Check this out to know more: https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
But, I think the most relevant solution to prevent internal and external threats is to configure your machine well and ensure the firewall covers all aspects. There are detailed guides for securing servers out there.

Q: How does wifi AP providers (e.g Starbucks,McD) pushes out "Sign In to surf website" notifications to customers, and how to implement that in JAVA?

I have 2 parts to my question. First is just a general question and second is more into app development and coding.
How does Starbucks/Coffee Bean/McDonalds pushes out notification whenever we as customers connect to their WIFI AP? They will push out notifications like "Sign In to proceed using the internet" in the status bar, and then redirects us to their website before we can start using the internet.
I am trying to create an app that does just that by creating a personal hotspot(that will have internet access), and whenever customers are logged into my hotspot, they will receive that same notification. My intention is to just direct them to a 'sign in' page in their browser, and once they click sign in, they will again be directed to my personal website. After that, they are free to surf any websites they want to.
So is it possible to do just that? I only want the app to be installed in my phone, and not in my customers phone.

I'm deducing a lot of this, but I don't see how else it could work.
The wifi hotspots you are referring to are themselves little web servers, in addition to being participants in the world wide web. When a browser sends a URL out, it eventually gets to a web server (we won't go into the DNS system here), and the web server -- a machine listening on one or two ports, ready to accept a URL via socket and return something in response -- responds to it.
In the case you're talking about, the little wifi web server stores the URL sent and, regardless of what it is, sends back the "login to continue" page, and ensures that it is responded to. Once it is, then it does its normal thing with the original URL, which in this case means it sends it out to the internet cloud for interpretation like a normal wifi hotspot would.
As future URLs are sent, the wifi hotspot ensures that the login has occurred -- perhaps it just uses the URL of the machine as a key to information about when it logged in last, or a cookie, there are a couple of ways -- and if there is a current login session, then it again passes the URL out to the internet cloud.
In order to do this in Java on your phone, you would need control of the socket input/output of the hotspot; you would have to be able to read the input, determine whether the login had occurred, and only then either pass along the incoming URL or store it so the login could take place. I don't know how you would do that.

What you describe is a "captive portal" - all new users connecting through the hotspot will have their HTTP requests redirected to this portal. Once you register, your IP-address is known and the redirect no longer occurs.
How this works on mobile devices is typically that when you connect to a hotspot your phone will try to access a well known address and when the redirection occurs to a HTTP-AUTH response it will then open the captive portal as part of the setup process. For instance in the case of the iPhone apple will try to access 'phobos.apple.com' which is why you'll often see this in the pop-up when you are trying to access a "other" website on an non-authenticated access point.
As regards doing this in Java, I think you will have a few problems on your hands. Typically Java only provides network access at TCP/UDP layers and above. Now what you could do is have your application acting as a "proxy" such that it relays all network activity through it, but this would be a heavy load for your application. It also would not have the transparency of the type of solutions you would be used to. Your users may also have to be told to access your site directly.
Your typical captive portal has a few different actors involved and a number of different protocols beneath the application layer. The Access Point needs to "know" whether a user is authorised or not (and thus is redirected to the portal, or gets to access the wider internet); The portal needs to be able to notify the portal upon authentication; 802.1x is used for the initial handshaking; DHCP to assign the IP-address based on MAC address.