For some specific reasons, I would need to automatically add or append a parameter to URL on every request if and only if that parameter already exists in URL since the first request. In other words, if I have the URL /share/page/site/sample/documentlibrary?embedded, every request to /share/page/site/sample/[whatever] must contain the embedded parameter plus other parameters that could be added by the original request.
I'm working with Alfresco Share (v4.2.b) what means that the web application already exists and despite of I can perform customization, I have limitations because I don't have full control on it. If it was my web app created from scratch it wouldn't be a problem. According to the restrictions I have, the solution ideally should be as less intrusive as possible. At the same time if it is a JavaScript based solution, the use YUI rather than other library is a plus but not a requirement.
I have been searching looking for an approach and after that I have in mind the next possible solutions:
Using JavaScript by adding the parameter to URL before every page unload. Something like:
window.onbeforeunload = function(e) {
// Add parameter to target URL
};
But I believe it doesn't work as I was reading and according to some tests I did. It seems there is a sort of security restriction (which makes sense by the way).
By updating the href attribute of every link (<a/>) using JavaScript too, once the page has finished loading. For example, /share/page/site/sample/document-details?nodeRef=workspace://SpacesStore/089acea3-3b37-403d-9a8d-ae484ddd2ccb could be transformed to /share/page/site/sample/document-details?nodeRef=workspace://SpacesStore/089acea3-3b37-403d-9a8d-ae484ddd2ccb&embedded. The problem of this solution is that both forms GET or POST and href triggered using JavaScript would be out of scope...
Using any URL rewrite technique or library like UrlRewriteFilter (didn't have time yet to test it, sorry).
Create an Alfresco Share extension module which changes or updates every request, maybe with the help of a module or subcomponent evaluator. I don't know if it is doable with extension modules, but I believe I read anywhere that you can perform changes to requests.
I have to add (for those with Alfresco Share knowledge) that options 1, 2 and 4 would be implemented as an extension module.
Well, I hope I have explained good enough my question. I'd strongly appreciate some advice or possible approaches. I will keep working on it anyway and I will come up with any update.
If it's for every request then a filter is the best. Share already uses the urlrewrite like you've stated so change the default one and add your parameter to it.
If you have knowledge of share then overriding the included template would be nice:
override alfresco-template.ftl which is in templates/org/alfresco/include. This template is always loaded when generating a page. It also has the portletMode defined for the Liferay Portlet.
What we've done to embed the documentlibrary is to define our own
share custom page, so I didn't need the 'always' present arg any
more.
What about proxying connections via Apache HTTPd using mod_proxy and then using mod_rewrite to redirect user requests if they do not already contain the mandatory parameter? Using the RewriteRule directive you can specify quite rich expressions that would add the parameter if it is not already there (docs)
Haven't used Alfresco but, one other option would be to have a custom JSP tag.
Lets call it customlink then when you render a link on the page use this custom jsp tag instead of an <a> tag.
E.g
<mynamespace:customlink href="/somelink">My Content</mynamespace:customlink>
The custom JSP tag can then be responsible for checking the query string parameter on the request and if it exists then appends it to the URL and prints the tag with the query string.
This has the benefit of not depending on JS or exposing any of this to the client side. It also allows further expansion in future.
Related
Currently my java code uses
response.sendRedirect(request.getRequestUrl().toString());
Which is an open redirect.
I have to fix this but I can not white list it since there are too many URL's are associated with it.
I have tried the following solution with ESAPI but it wont work for me.
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
I am new to ESAPI.
[Disclaimer]
I'm project co-lead on ESAPI.
I have to fix this but I can not white list it since there are too
many URL's are associated with it.
Essentially, "I have to fix the problem, but I am restricting myself from the easiest solution."
Here are the best practices enumerated by #jww:
Simply avoid using redirects and forwards.
If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
Sanitize input by creating a list of trusted URL's (lists of hosts or a regex).
Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.
These are literally all the solutions available to you. Some web frameworks make this easy for you, like Spring MVC with Spring Security.
These lines:
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
Don't work because you have to inspect the user input before performing the redirect.
You definitely are going to want to white-list this, at least at a minimum, based on domain names. Restrict it as much as possible. E.g., if your app is hosted at https://myApp.example.com/ redirecting to anywhere on your site is probably okay. (I write probably, because if it can be used as a way to bypass authorization checks, say on a multi-sequence page series, then it might not be okay. But as long as your regular authorization checks pick up and validate the redirect, you generally will be okay.) But what about redirects to https://anotherApp.example.com/? Would those be okay? What about anything in the "example.com" domain? Are their other 3rd party domains that you need to white-list? If so, be sure to list those URLs as well. But the one thing that you want to avoid are completely open redirects and for that you need some type of white-listing. You could build some custom validators using ESAPI to do this, but it's probably just easier to write it without ESAPI. If you have a bunch of URLs that you have to white-list, keep them in a configuration file that's not part of your .war / .ear file so you can easily update it without redeploying your application and just (re)read the config file when it gets updated.
Hope this helps.
-kevin
Thanks for all your suggestions and comments.
I found that the lines
ESAPI.httpUtilities().setCurrentHTTP(req, resp);
ESAPI.httpUtilities().sendRedirect(location);
ESAPI.httpUtilities().clearCurrent();
Is now working fine for me, after a long struggle I found that my code is using latest version of commons-configuration.jar but when I added Esapi as a dependency the Esapi used an old version of the same and that was not compatible with my code so I just excluded the this from Esapi dependency using the exclusion in pom and it worked for me.
In GWT i need to use # in URL, in order to navigate from one page to another for eg. www.abc.com/#questions/10245857 but due to which i am facing problem in sharing the url.
Google scrappers are reading the url only before # i.e. www.abc.com.
Now i want to remove # from my url and want to keep it straight as www.abc.com/question/10245857.
I am unable to do so. Please help me with some links or code.
Thank you
If you want URLs that don't use the hash, then you have to use HTML5 pushState (browser compatibility).
You cannot do that if you use the History class directly; you'd have to create your own History class that use pushState and use that class in your code instead of the GWT built-in one.
If you use Places, then it's much easier as all you have to do is implement an Historian rather than use the DefaultHistorian; e.g. https://gist.github.com/tbroyer/1883821
If you need to support browsers that don't have pushState, then things get much more complex.
There are alternatives though:
you can use #! and implement the necessary server-side hooks: https://developers.google.com/webmasters/ajax-crawling/ (there are projects that implement this by running your GWT app within an HTMLUnit pseudo-browser on the server; IIRC, GWT-Platform has such a feature)
you can provide permalinks to your "places", like Google Maps or Google Groups do; see https://stackoverflow.com/a/24717441/116472
The # represents places inside the application so to change the URL try Creating different GWT entry point modules could solve this issue – there would be only one web application this time, but each module would be accessible via a different URL. Look into this article http://www.summa-tech.com/blog/2011/02/22/structuring-gwt-modules-for-large-applications/
My GWT app URL when a page is access looks like this:
http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997#ViewPage;hash=6a
or
http://127.0.0.1:8888/index.html#ViewPage;hash=6a
However, this does not look good, is there a way for the GWT client side code to make it look like this, to "mask" it somehow to:
http://127.0.0.1:8888/6a
Where I have a servlet configured to forward this "shortened" URL to the long URL above so its very safe to make the URL "masked"? Without losing state and history.
The shortest possibility I know would be an URL like:
http://127.0.0.1:8888/#6a
Therefore you must configure index.html as default page. (It must be configured as default response).
You also have to rewrite the history-management. You have to remove the Place-Token from the URL.
I don't see any way to do this directly with GWT, since GWT needs access to the code fragment in the URL to manage browsing history and state.
One indirect way to do it would be to embed your GWT module inside an iframe that occupies the whole page area. The drawback is that the user would loose the ability to bookmark pages inside the GWT application.
By the way, I don't share your view that it "does not look good". Many popular Web applications use the URL like this, including Gmail. Most users don't care about what's in the URL.
We have a website which is coded Java with Struts Framework. The WebSite's Urls are not seo friendly. All of them are like below
../buyerApplication.do&companyId=2323
Now We want to make these URLs SEO friendly and I searched and found these solutions:
tuckey.org/urlrewrite : but i don't rely on this system.
adding
title end of link after '&' such as
"../newsId=33233&does-art-in-the-city-equal-art-for-the-city"
: In this solution I am not sure it
works well.
I am waiting your sugestions to solve this problem best.
I actually used URLRewriter (http://tuckey.org/urlrewrite/), which you referenced in your original question. It was very easy to set up and filled my needs perfectly.
To the point, you need a Filter for this.
If you want to keep your existing application's architecture, you'll need to define and create a set of rules to convert unfriendly urls to friendly urls and let the filter convert it and forward the request to the unfriendly url.
If there is no means of modifying an existing application but you want to create a new application based on this idea, you could consider to having a single page controller which translates the HttpServletRequest#getPathInfo()/getRequestURI() to execute the appropriate action class (command pattern) and finally forward the request to the appropriate JSP page. Not sure how that would fit into Struts as I haven't worked with Struts previously.
For what it's worth, you can also look at the REST plugin http://struts.apache.org/2.x/docs/rest-plugin.html, which amongst other things will make your URLs more friendly
I'm trying to create a series of sites that all run as one application, but have different designs (to localise them).
My idea is to map separate domain names to the one site. E.g: www.mysite1.com maps to www.mysite.appspot.com/mysite1 and www.mysite2.com maps to www.mysite.appspot.com/mysite2
I'm guessing that there must be a url pattern or something to pass a servlet the name of the site from web.xml? I'd like urls such as www.mysite.appspot.com/mysite1/forumpost/3/ to be able to be handled by the same servlet as www.mysite.appspot.com/mysite2/forumpost/3/.
Ideally I'd like to pass the site name as a parameter to the servlet.
Surely there is someone that has done this before, or some standard way of doing this? I've got a fuzzy idea about parsing the url to take the site name out of it, but I'm pretty new to servlets etc and thought that someone might be able to shed some light on this situation.
Thanks!
You can't map your own subdomains of appspot.com apps (eg, foo.mysite.appspot.com), but you can map arbitrary domains to your app directly, such as www.mysite1.com and www.mysite2.com - just add them all as aliases to your Google Apps account, and then map them to your App Engine app. Once you've got that done, you just need to check the content of the Host header in your app to route requests to the appropriate handlers (or otherwise vary the content you return).
Try using a javax.servlet.Filter and forwarding to the language specific pages based on the HTTP request header 'Accept-Language' (I think that's the one). You can get at that with a call to javax.servlet.HttpServletRequest.getHeader(String).
This way your site has a single URL and the separation into language specific pages is handled internally.