AEM 6.x: How do I temporarily/programmatically disable the link checker? (trying to return a JSON with links back to browser) - aem

So I have a Sling servlet that reads data from another API (let's call it APIX) and APIX gives me the data in JSON format.
When I debugged my code, it seems the response I get from APIX is intact.
When I pass the JSON I got from APIX to browser, I can see that AEM has "link checked" all the links I have in the JSON. I don't want AEM to do anything with my data.
Base on this Adobe page, I added these lines in my code:
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
LinkCheckerSettings linkCheckerSettings = LinkCheckerSettings.fromRequest(request);
linkCheckerSettings.setIgnoreExternals(true);
//body of the code here
response.setCharacterEncoding("UTF-8");
response.setContentType("application/json;charset=UTF-8");
printWriter.write(jsonResponse);
linkCheckerSettings.setIgnoreExternals(false);
}
No effect. I can still see these string
<img src="/libs/cq/linkchecker/resources/linkcheck_o.gif" alt="invalid link: _blank\\" title="invalid link: _blank\\" border="0">
everywhere.
I then tried disabling Linkchecker (via configMgr/Day CQ Link Checker Transformer) and still no effect.
How can I do it?
I called the Slng servlet by typing this URL in my browser: http://localhost:4502/servlets/getpublications?name=john.smith
Thanks!
EDIT:
This is a sample of the JSON data I'm getting from APIX (debugging on IntelliJ):
"LINKS":[
"<a x-cq-linkchecker=\"skip\" target=\"_blank\" href=\"http:\/\/www.google23.com\">[Web Link]<\/a>"
]
This is what I'm getting on the browser (the a tag was somehow replaced by an img tag)
"LINKS":[
"<img src="/libs/cq/linkchecker/resources/linkcheck_o.gif" alt="invalid link: _blank\\" title="invalid link:_blank\\" border="0"> [Web Link]<\/a>"
]
I have tried using valid and skip for x-cq-linkchecker but nothing happens.
Day CQ Link Checker Transformer config screenshot

I don't think disabling LinkChecker at a global level is recommended. There are a few more ways you can achieve this and place the restriction to only certain use cases -
If the link contains special prefixes like tel:, mailto: etc, - you'll have to add them to Day CQ Link Checker Service in /system/console/configMgr to disable LinkChecker for these links.
Add this parameter x-cq-linkchecker="valid" to the <img> tag to ensure links are marked as valid in AEM - even though AEM considers them invalid.
You can also use x-cq-linkchecker="skip" to skip link checker validation for this element.
You might encounter caching issues after updating the above params(2. and 3.), just try deleting contents in /var/linkchecker before you start testing.

There are multiple techniques for handling special url patterns, Refer here. And a very good link checker guide here.
Technique 1: Code way(Not recommended since not maintainable). Add class x-cq-linkchecker=”skip”
Technique 2: Disable link checker. Definitely not recommended in author. Author should witness broken links visible. However it is recommended to disable in publish rather than showing ugly broken link icon.
Technique 3: Add special url pattern. Your link checker should looks like this:

Related

codename one sharebutton 400: Bad Request

I've been trying to use the native sharebutton integrated into the Codename one project, except that when I click "Post", a "400 : Bad Request" error appears. No exception is thrown, and I have no stacktrace in my console.
Code :
ShareButton sb = new ShareButton();
sb.addActionListener((evt) -> {
System.out.println("clicked");
});
hi.add(sb);
sb.setImageToShare("file://home/230r3EdWRk4kP6WDiMBM", "image/jpg");
sb.setTextToShare("Test facebook");
hi.show();
Another inssue is that the text to share is invisible.
Screenshot
400 just means bad request. This could be for many reasons. Make sure that the file path you provided exists etc..
AND
I seem to recall that Facebook no longer lets you share an Image and text at the same time. You can do one or the other. If you want to share something that has an image and text, you need to create a dynamic webpage that uses their Open Graph Markup, and share a link to that. Then it will be formatted nicely in the news feed.
It's been a while since I've had to do this, so I'm going by memory here... Things could have changed.
Thanks,
I fixed my problem by following the Facebook Demo at this link :https://github.com/codenameone/codenameone-demos/tree/master/FacebookDemo
Turns out that there are issues with the builtin share button, so you need to use multipart requests.

Play Framework: Don't change URL after form validation failed

In a plain Play application I have the following scenario.
A route file which looks like this:
GET /accounts/add controllers.Accounts.add()
POST /accounts controllers.Accounts.create()
The first route results in a view where I can add a new account. The form to submit the new account looks something like this:
#helper.form(action = routes.Accounts.create()) {...}
Now the controller binds the input to the form and checks for any validation errors:
public static Result create() {
Form<Account> form = Form.form(Account.class).bindFromRequest();
if (form.hasErrors()) {
return badRequest(views.html.account.add.render(form));
}
...
}
Now the thing is, the client will see the same view with some additional error messages. However, meanwhile the URL has changed from http://example.com/accounts/add to http://example.com/accounts.
If the client now reloads the browser this calls GET http://example.com/accounts (which isn't even mapped in this scenario - thus getting a 404 - Not Found).
Maybe it's just me but I find this kind of annoying and browsing some GitHub projects I couldn't find a good solution for this case.
Of cause things would be much simpler if the second route is rewritten to:
POST /accounts/add controllers.Accounts.create()
... in which case everything works fine. But from a REST point of view this doesn't feel good either. The same applies to update scenarios (having GET /accounts/:id/update vs. PUT /accounts/:id).
Is there a guide on how to handle this? Am I getting something wrong or is this no problem at all (from a pragmatic point of view)?
It's not possible to leave the previous URL because a request for a new address has already been made. A controller only provides response for a requested resource. To go to the previous URL you could only make a redirect in case of validation failure but you would lost errors that way so this is not a solution.
I suggest mapping both actions with the same URL. This way you would solve problem with the browser reload.
If you create a REST service for http clients that aren't browsers you will probably want to serve different response than a simple http page. The separation of actions for particular clients could be a good solution for keeping REST API clean and a browser user happy.

URL fragment lost as part of SAML token authentication; workaround / standard pattern?

Several web application authentication protocols (like WS-Federation and the SAML protocol, i.e., so-called 'passive' protocols, and apparently also ASP.NET Forms authentication, see this StackOverflow question, and AppEngine, see this GWT bug comment) lose the original 'URL fragment', i.e. the part after the #-sign.
What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) http://example.com/myapp/somepage?some=parameter#somewhere. This makes the browser request (2) http://example.com/myapp/somepage?some=parameter, the server redirects me to my identity provider (including URL (2) in the authentication request), and ultimately I'm redirected back to where I came from, which is URL (2): that is the only URL that the server knows about. But I wanted to go to URL (1), and the URL fragment ('anchor') has been lost along the way, actually in the first step already.
This seems to be a fundamental limitation of these protocols, since the server never sees the URL fragment at all.
I know that it according to specifications that the browser requests (2) from the server, when I navigate to (1), leading to this fragment-losing limitation on the SAML protocol, WS-Federation, etc. My question is: how do I work around this limitation?
The obvious workaround is to avoid URL fragments, as suggested in this answer. However, for our specific web application that is not nice, since we use bookmarkable URL fragments in our single-page GWT application, to make sure that a navigation within our application does not cause the page to reload.
My question: What other workarounds or standard patterns are there for this situation?
(I'm specifically interested in a GWT + SAML protocol solution.)
You basically have two options:
avoid using location.hash (use HTML5's pushState instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)
do the redirection using JavaScript. I.e. instead of sending a redirect from the server, send an empty HTML page with some script that takes the full URL (with the hash) and does the redirection using location.assign() or location.replace(). With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.
You can of course do both: if the link is a deep-link into the app, then do the redirect (i.e. assume there's no hash), otherwise send a page with JS to make sure you don't lose any state present in the hash.
And finally the obvious third solution, far from ideal: don't do anything, and try to educate users that when they needed to (re)authenticate then they should re-paste the URL or re-click the link or re-click the bookmark.
According to RFC 1738 anchor tags are not sent by the client to the server, when requesting for a resource.
Anchor tags are used to identify a location within a resource and not a different resource on the server. In order to identify the location in the resource, the client needs to fetch the complete resource from the server, and this process need not involve transfer of information about the fragment (as it does not mean anything to the server).
If you do wish to send the fragment character (#) to the server, then you'll need to encode it in the query string, or the client(browser) will simply ignore that section of the URL when it sends the request to the server.
EDIT:
I don't know any real solution but to work around this issue you need to save your full return URL (with anchor tags) somewhere on the client side, because server don't know anything about anchors. For that you could use SessionStorage (http://www.w3schools.com/html/html5_webstorage.asp) to temporary store ReturnUrl until login process is completed. Please note that it won't be supported on older browsers (like <= IE7).
In that case workaround would look something like this:
<script>
if(typeof(sessionStorage) == 'undefined')
{
sessionStorage = {
getItem: function(){},
setItem: function(){}
};
}
window.onload = function ()
{
var key = 'ReturnUrl';
//try to get last returnUrl with anchors
var returnUrl = sessionStorage.getItem(key);
//if we got something, do the navigation
if(returnUrl !== undefined && returnUrl !== document.URL)
{
//clean it up
sessionStorage.setItem(key, null);
//navigate to last URL
window.location = returnUrl;
}
else
{
//store url
sessionStorage.setItem(key, document.URL);
}
}
</script>
PS. Bear with me if there are some syntax errors because I wrote it down from top of my head and didn't try it.

Google Search autocomplete API?

Does Google provide API access to autocomplete for search like on the actual site? I have not been able to find anything.
I would like to use Google's autocomplete logic for web search on my own site which relies on Google's search API.
The new url is:
http://suggestqueries.google.com/complete/search?client=firefox&q=YOURQUERY
the client part is required; I did't test other clients.
[EDIT]
If you want the callback use this:
http://suggestqueries.google.com/complete/search?client=chrome&q=YOURQUERY&callback=callback
As #Quandary found out; the callback does not work with client "firefox".
[EDIT2]
As indicated by # user2067021 this api will stop working as of 10-08-2015: Update on the Autocomplete API
First, go to google, click Settings (bottom right corner), change Search Settings to "never show instant results. That way, you'll get regular autocomplete instead of a full page of instant results.
After your settings are saved, go back to the Google main home page. Open your browser's developer tools and go to the Network tab. If you're in Firefox, you might have to reload the page.
Type a letter in the search box. A new line should appear in the Network window you just opened. That line is showing where the autocomplete data came from. Copy that url. It should look something like this:
https://www.google.com/complete/search?client=hp&hl=en&sugexp=msedr&gs_rn=62&gs_ri=hp&cp=1&gs_id=9c&q=a&xhr=t&callback=hello
You'll notice your search term right after the part that says q=.
Add &callback=myAmazingFunction to the end of the url. You may replace myAmazingFunction with whatever you want to name your function that will handle the data.
Here's an example of the code required to show the autocomplete data for the search term "a".
<div id="output"></div>
<script>
/* this function shows the raw data */
function myAmazingFunction(data){
document.getElementById('output').innerHTML = data;
}
</script>
<script src="https://www.google.com/complete/search?client=hp&hl=en&sugexp=msedr&gs_rn=62&gs_ri=hp&cp=1&gs_id=9c&q=a&xhr=t&callback=hello&callback=myAmazingFunction"></script>
Now that you know how to get the data, the next step is to automatically change that last script (the one with the autocomplete url). The basic procedure is: each time the user types something in the search box (onkeyup) replace the search term (q=whatever) in the url, and then append to the body a script with that url. Remove the previous script so that the body doesn't get cluttered.
For more info, see http://simplestepscode.com/autocomplete-data-tutorial/
Most of the above mentioned methods works for me, specifically the following serves my purpose.
http://suggestqueries.google.com/complete/search?client=firefox&q=YOURQUERY
Being a newbie in web programming, I'm not much aware of the "Callback" functionality and the format of the file returned by query. I'm little aware of AJAX and JSON.
Could someone provide more details about the format of file returned by the query.
Thanks.
Hi I don't know if this answer is relevant for you anymore or not but google returns JSON data through following get request (although this isn't an official API but many toolbars are using this API so there's no reason why google might discontinue it):
http://google.com/complete/search?q=<Your keywords here>&hl=en
You should use AutocompleteService and pass that text box value into the service.getPlacePredictions function. It send the data in callback function.
let service = new google.maps.places.AutocompleteService();
let displaySuggestions = function(predictions, status) {
}
service.getPlacePredictions({
input: value
}, displaySuggestions);
Base: https://developers.google.com/maps/documentation/javascript/reference/places-autocomplete-service#AutocompleteService.getPlacePredictions
example: https://dzone.com/articles/implement-and-optimize-autocomplete-with-google-pl
I'm using (( Edrra.com )) API that have google search and suggestions that works with both GET & POST:
Google suggestions:
https://edrra.com/v1/api.php?c=google&f=suggest&k=YOUR_API_KEY&v=YOUR_SEARCH
Google search:
https://edrra.com/v1/api.php?c=google&f=search&k=YOUR_API_KEY&v=YOUR_SEARCH
and more...
What are you trying to use an auto-complete for? More information would help narrow it down.
As far as I know, google does not provide one, but they do exist like jQuery UI's auto-complete.
EDIT:
If you are using their custom search API view here for autocomplete.

Handling 'A potentially dangerous Request.Form value was detected from the client'

I am trying to figure out how to handle this error.
A potentially dangerous Request.Form value was detected from the client
The error occurs when a user enters in html or xml tags( <p> or <HeyImXML>) and tries to submit a form. The input is not supposed to contain any sort of markup at all, just plain text.
I am using model binding validation in ASP.NET MVC 2.0 along with Html.EnableClientValidation. This works fine as long as there is no markup entered.
What is the best approach on how to avoid this error message?
My guess is to write a new validation class which checks for this kind of markup?
I want to catch the error in this specific instance. To clarify there is an area with a form for siteadmins that can enter markup and there is a normal users area where they can not enter markup. However this error page appears when a normal users enters markup. My question is, how do I handle this to prevent the site from crashing and showing the error page. I want to display a cleaner error.
MVC will automatically protect your application from some html injection and cross-site scripting (XSS) attacks. This is why you will get the "A potentially dangerous Request.Form value was detected from the client (...)" by default when attempting to post html/javascript.
However, we may sometimes want to allow our users to post html. You might just want to allow users to use characters such as "›", or it might be because your implementing blog functionality and want to support tags like ‹h1›, ‹div›, etc. This can easily be accomplished with MVC by disabling request validation.
Add [ValidateInput(false)] attribute to the action method in the controller you are calling. This will disable request validation for the entire model on the specific action.
Another way is to add the [AllowHtml] attribute to the property which requires html in your model.
These two attributes will only allow html/javascript to GET IN to your application, but MVC will still output them safely by using html encoding. If you want to output it like html, you can use the #Html.Raw(#Model.Content). But use this with caution, since this will open your application to cross-site scripting attacks (XSS)!
i found this solution from some one's blog
also see below code for your solution
you can handle errors within your application in the following way
1. Setting the CustomErros mode section in your Web.Config file of your application
This the lists of options the mode attribute can accept.
RemoteOnly: Generic error pages are shown for remote users. Rich error pages are shown for local requests (requests that are made from the current computer). This is the default setting.
Off: Rich error pages are shown for all users, regardless of the source of the request. This setting is helpful in many development scenarios but should not be used in a deployed application.
On: Generic error pages are shown for all users, regardless of the source of the request. This is the most secure option.
<System.Web>
//map all the erros presented in the application to the error.aspx webpage
<customErrors mode="RemoteOnly" defaultRedirect ="~/error.aspx" />
<System.Web>
2. throught Global.asax file in the Application_Error function
//handle all the errors presented in the application
void Application_Error(object sender, EventArgs e){
Server.Tranfer("error.aspx");
}
I hope this works for you.
from stackoverflow solution
This was introduced early on in ASP.Net to try to help prevent script injection attacks. It isn't unique to MVC.
If you don't want this feature, you can turn it off and write your own.
To disable request validation on a page, set the validateRequest attribute of the Page directive to false:
<%# Page validateRequest="false" %>
To disable request validation for your application, modify Web.config - set the validateRequest attribute of the <pages /> section to false:
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>