I need to log the requests to my Web server. Every request should be logged to the file with name format "ClientIP.log", where ClientIP is an IP address of a client from which the request came from. How can I follow this requirement using NLog?
This can be done using the NLog AspRequest layout renderer.
See https://github.com/NLog/NLog/wiki/AspRequest-layout-renderer
To get the remote ip address you would use the remote_addr server variable.
${asp-request:serverVariable=remote_addr}
For example:
<target name="..."
xsi:type="File"
fileName="${basedir}/logs/${asp-request:serverVariable=remote_addr}.log" />
It is also possible to write you own layout renderers which allow you to define your own context information based on the request. This is explained in detail in this question: Most useful NLog configurations.
Related
Say we have an internal URL https://my.internal.url (in our case a Liferay Portal) and from a web application firewall an external URL https://my.external.url pointing to this internal URL.
The internet user is using the external URL.
PrimeFaces extends attributes like for example
onclick="...;window.open('https://my.interal.url'..."
This leads to CORS problems.
The HTTP header Access-Control-Allow-Origin is not an option, since the internal URL is internal.
We'll talk with the WAF people about URL replacement, but I'd like to know wether or not we can tell PrimeFaces to use the external URL (or maybe relative URLs in case this would work).
The portal doesn't know about the external URL but of course we could implement this as a configuration option.
(watching the source code, there are more occurences of the internal URL outside of the jsf/PrimeFaces portlet, so I add the liferay tag too)
Update
The question is obsolete, WAF has to handle this correctly (an old SSL environment did it, a new WAF environment doesn't)
You say
The portal doesn't know about the external URL
however, any properly configured reverse proxy (or WAF) should forward the actual host name used to request the current page.
On Apache httpd's mod_proxy_http, this is done with the option ProxyPreserveHost On. When forwarding with AJP, the host is automatically forwarded. Other WAF/Proxy configurations - of course - differ. But the proper way to generate the URL is to let the generating server know what URLs it should generate.
If you need to worry about the proper host name, you'll need to do so by request: Liferay is well able to use Virtual Host names to distinguish between different sites - and if they're completely different, you might be signed in to one of them, but not to the other. This has a repercussion on the permissions.
Have the infrastructure handle it for you. Don't write code (or application configuration) for it.
I am facing an issue where server header information is showing up in IIS. I know by using URL rewrite module and creating outbound rule will resolve the issue. Problem here is when i am checking individual severs i am seeing server header information as Server:-Microsoft-IIS/7.5. and when i am checking LB URL i am seeing server:- IA Web server. not sure from where this text is coming up.I checked the web.config file but the entry for witting own server information is not present in an tag. Also one more information i have akamai implemented after the web servers. Could some one help in this context.
This is added by IIS Server. Adding outbound URL-Rewrite rule is the best way to go as adding a custom HTTPModule to remove headers or through global.asax.cs as explained in this answer won't work for static files.
See detailed blog here - https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/
We have a domain name with DNS management facility. We also have a web application developed in a GlassFish server hosted in a virtual server with a path is
http://198.98.103.233:8080/pemis/
I want to direct to the home page of that application when some one type the domain name. After navigating through the pages, we must be able to see
http://www.pemis.lk/faces/public.xhtml
in the browser rather than
http://198.98.103.233:8080/pemis/faces/public.xhtml
How can we configure that.
Thanks in advance.
You need to install your application as the root application in Glassfish, as explained here. But it's not hard:
asadmin deploy --contextroot "/" your-webapp.war
or set the context-root property in the sun-web.xml or glassfish-web.xml depending on the version of Glassfish you use.
To change the port Glassfish listens on you need to modify the HTTP Listener configuration. On default installations you'll want to change http-listener-1's port. You can do so using the console. But you can also directly edit the domain's domain.xml:
<network-listeners>
<network-listener port="80" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
...
</network-listeners>
Last, to make www.pemis.lk point to that server you need a DNS entry that points to the address the server is attached to. The details of how to do that depend on the comapny that sold you the domain, quite often they have online tools that allow you to enter or modify the name-address mapping. In case of doubt it's best to contact them by phone or mail.
I'm on the same path and, as you don't posted the solution that you found (if you found it), I'll add here some future reference for anyone facing this problem.
I'll break the question in two parts: Eliminating host:port and changing how the URL behave.
I don't have a complete response to the first, however if you chose to listen at port 80, by HTML standard, you will supress the port on the URL, getting half the solution you want.
The second part, changing the URL behavior and/or shortening it can be achieved by either using mod_rewrite in apache or Tuckey's URL Rewrite Filter (http://www.tuckey.org/urlrewrite/). A google search using URL Rewrite can achieve you a more in depth explanation and there's a guide on the website.
You should, however, update your question with an answer, if you found one.
Consider the following test view using Seam's Excel library:
<e:workbook type="csv">
<e:worksheet name="Export" >
<e:cell value="1" row="0" column="0"/>
<e:cell value="2" row="1" column="1"/>
</e:worksheet>
</e:workbook>
I'd like to secure parameters to a more complicated version via HTTPS. The unsecure view generates the file fine. When I change the scheme to "https" in view.page.xml, instead of my csv file, the browser is redirected to http://localhost/seam/docstore/document.seam with the conversation id in the query string. Other pages secured using https (e.g. login) are working fine.
Any suggestions on resolving or better diagnosing the problem?
Thanks!
It could be related to your security constraints settings in web.xml. Take a look here.
If excel is trying to access resources outside of the restricted area you won't be able to generate the file.
I'm using a staging model with MSDeploy to deploy a couple of our sites to a web farm. The sites are configured in IIS on the staging boxes only, and then MSDeploy is used to build the target web servers from scratch.
The staging box uses its own bindings (ie no header entries, different IPs/ports and no host headers) for the sites that will be live. When I deploy them I first have an xml file used to prepare a parameterised package (using the -declareParamFile switch) which declares parameters as follows:
<parameters>
<parameter name="site1">
<parameterEntry kind="DestinationBinding" scope="Site1" match=":17000:" />
</parameter>
</parameters>
So in the above XML you can see that the staged site is hosted on port 17000 as the match attribute is set to match a binding that has that value.
When I then deploy to each live site, I use a different parameters XML that specifies the correct host header and IP for that machine - I apply this using the -setParamFile switch. Here's an example of one of them.
<parameters>
<setParameter name="site1" value="[ip_addr]:[port]:[host_header]"/>
</parameters>
So, because the original parameter is declared to match one of the known bindings - I can replace that binding with what I actually want it to be on each live server.
What I want to do now is to deploy the site and add new destination bindings to it that incorporate the different TLDs that we have - i.e. site.com, site.co.uk, site.ca etc, all bound on the same IP address and port.
The reasons for wanting to do this are:
We have a new site that we want to deploy that will need a different hostname, but we don't want to give it it's own IP address (running out of IPs here!) but have it share the IP that an existing site on the servers already has.
This means adding specific hostname bindings to the site that's already on there, instead of having it respond to any hostname.
We have four domain names currently pointing to the existing site's load balanced IP(.com, .us, .ca, .com.au). At the moment it works because the web server doesn't care about the host header - but when the new site goes on the same IP, it will, and the other domain names will no longer work.
The problem is I don't think there appears to be any way of adding such information. I've tried adding multiple setParameter elements in the second XML, but that simply has the effect of repeatedly overwriting the binding, with the last one as the eventual winner.
One solution is for me to add 'placeholder' bindings for each of the sites on the staging box, which represent the target external bindings for each domain name, port etc; and then I modify the two parameters files to replace those bindings with the real ones.
But to me this feels completely wrong - that would be modelling the staging box to suit the live deployment; it should be the other way around.
Is it possible to actually add site bindings with MSDeploy (if so, how?), or does it only support replacement?
After much head-banging, it appears that there is no way to add new bindings using the DestinationBinding operation with msdeploy.
What would be possible would be to attach a script to be executed after deployment that adds the bindings using appcmd every time.
So, the initial synchronisation via msdeploy would remove those bindings (because they're not on the staging server) but the appcmd script would then add them again.
Not really an ideal solution, though, as it's yet another script that has to be kept up to date.