I have two application written in lift with embedded jetty. The first one is maintaining session based on SessionVar implementation. And that is working great without any problem.
In second application I am using Basic Authentication, which is also working great.
The problem arises when I open both applications in the same browser in different tabs. Even though both applications are running on different ports, the second application causes first to session out.
Does any one have got any idea what's the problem is and how do I resolve this issue?
I am using scala 2.9.0.1 and lift 2.4-M1.
The HTTP port does not affect session management at all. The web server will see them as the same thing. If you want to run them both concurrently, perhaps try accessing one at 127.0.0.1 and the other at localhost, thus negating the issue of them being on the same perceived host.
FWIW, LiftSession is not instantiated at the time of basic authentication; i'm pretty sure its cached by the browser and not by Lift.
Related
I have an old apache web server, with some security issues, that running an old application exposed by internet. Before upgrading apache version, I must perform a lot of tests in a dev environment. During this time I would put a reverse proxy (with last apache web server version) in front of this application.
This temporary workaround can resolve some old apache security issues or it is totally useless?
Thanks in advice and I'm sorry for my bad english.
This temporary workaround can resolve some old apache security issues ... ?
Yes, with "can" and "some" emphasized. A reverse proxy handles incoming requests and rewrites them in a canonical form, which is safer for the application server to parse. A reverse proxy can also reject malformed requests so that they never reach the application.
It might not resolve every security issue, but you imagine one that this would resolve. For example, if a specially crafted causes the older version to execute arbitrary code, while the new version would drop the request, then having the reverse proxy would help prevent this bug from affecting the application server.
It's not as much of a defense as using a web application firewall, but it's kind of related.
I am coding a mac app, which will be a server that serve files to each user's mobile device.
The issues with this of course are getting the actual ip/port of the server host, as it will usually be inside of a home network. If the ip/port changes, its no big as i plan to send that info to a middle-man-server first, and have my mobile app get the info from there.
I have tried upnp with https://code.google.com/p/tcmportmapper/ but even though I know my router supports upnp, the library does not work as intended.
I even tried running a TURN server on my amazon ec2 instance, but i had a very hard time figuring how what message to communicate with it to get the info i need.
I've been since last night experimenting with google's libjingle, but am having a hard time even getting the provided ios example to run.
Any advice on getting this seemingly difficult task accomplished?
The port of your app will not change. The IP change could be handled by posting your servers IP to a web service every hour or whatever time period you want.
Server should run a URL http://your-web-service.com/serverip.php?ip=your-updated-ip and then have your serverip.php handle the rest (put it into a mySQL db or something)
When your client start it should ask your site for the IP and then connect to your server with that.
This is a pretty common way of handling this type of things.
I tend to get this annoying error alot using Netbeans 7.2. The that occassionally comes up is,
Starting of Tomcat failed, the server port 8084 is already in use.
I'm part of a small group of developers and a couple of us have encountered this, and our solution is to go simply kill the Java process using it.
However, our boss insists that this isn't necessary and that my "Duct-tape solutions" are NOT adequate.
It's not a task given to me or anything, but it is annoying and I'm wondering if he's right. Is there a permanent solution to this Apache Tomcat error? Is there some way for me to configure Apache Tomcat so that this won't happen again?
Update
That would also work, but I don't see how that's any better than me going in and killing the stupid process. Your solution would only mean I have more than one instance of the same app server running. But, what I wanted was a way to prevent the stupid Apache Tomcat instance from still staying up even though I wanted to kill it using the IDE.
Use a different port for the Tomcat. You can easily change the port number in net-beans by simply moving on to servers>tomcat and right click .. properties. and change the port to say 8083 etc...
I may be giving entirely the wrong information here, but at the moment we're a bit unsure where to look for the issue. We have a server running on WebLogic, of which version I'm not sure.
Our site has an installer that clients need that can run around 15 MB. Normally, this downloads perfectly fine, but we've recently been finding issues in the download where the browser reports it completed, but the installer can't be opened - it appears that the filesize isn't what it's expected to be either, like the download was just cut off.
The issues are relegated to instances where the user is on a spotty connection, such as a 3G card in their laptop.
It seems to happen mostly on Macs, but it seems like that's because the mac .dmg file is much larger than the windows executable. Still, from my knowledge of network protocols, a spotty network shouldn't cause the specific issue we're seeing.
At the moment, we're debugging several of the layers of the transfer, like our firewalls, but with my meager knowledge of Weblogic, I'm kind of curious if there is something we could be missing in the server's configuration itself.
Unfortunately, I'm not sure if I am able to post the configuration files here - I'm pretty sure at the moment, there are no servlet rules created specifically for the installer's directory - but I was hoping someone here might at least recognize this type of issue and be able to point me in the right direction.
Check if you have any maxpostsize limit set.
Check for the responses that has failed if there's any socket timeout errors seen in the log file.
If you are using a proxy, check for error there related mainly to sockets.
Such issues can come when a tcp socket is timed out at the firewall end, WLS end, Frontend proxy like apache end.
There are few other settings like http connection timeout I think in WLS.
check from admin console-server-protocol-general tab or http tab.
I am having some problem in writing jade script.So am wondering if i could host my webpages
on apache. Once the page opens it will open a socket to port 3000 and then node server will start pushing notifications.
Will it give some warning in browser? any other concern with this approach?
So Apache willl run on 80
node on 3000
I had done this once for testing purposes, works well, no warnings were given.
Concerns would be that splitting website background on two servers will bring an extra complexity to the project. If you will load any parts from node initially, it will cause longer loading time, because you will only be able to establish connection to node when main page from apache will finish load. Also there is a possibility of duplicated code doing same thing under different servers.
In conclusion I would say that if there is no special needs from other servers, I would try my best to keep everything on node with jade, even if that would require some learning, it will definitely payback later.
If the only reason you're using apache is to serve the initial page, I would suggest the nginx in that case, because it is more lightweight but I haven't tested it by myself.