I'm having one Rest API: /myApp/fetchData/User-Name/Password. User-Name and Password will be changed based on the request.
When i call the above restapi like this
/myApp/fetchData/srikanth/Abcdef#g123
the request is going like this:
/myApp/fetchData/srikanth/Abcdef
Basically in the URL text got removed from # character. Is there any way to solve?
Thanks,
Srikanth.
In a URI the # triggers the begins of the "fragment", and ends the path. The fragment usually specify a portion of the resource identified by the path.
When you are post-ing the request from the client, you have to escape special characters. Your request should be:
/myApp/fetchData/srikanth/Abcdef%23g123
There are different way to escaping urls, like the encodeURI or encodeURIComponent function in JS. For example, you may do:
var request = "/myApp/fetchData/srikanth/" + encodeURIComponent("Abcdef#g123");
Then the server have to decode back to the original request.
But: are you sure it is a good solution to send the password plain in that way?
Related
This is my route. I want to send a file to an Azure blob. I want to set the name of the blob as the file name without extension. I also want to filter out the whitespaces from the file names. I am thinking of using an interceptor
from("file://C:/camel/source1").recipientList(simple("azure-blob://datastorage/container1/${header.fileName}?credentials=#credentials&operation=updateBlockBlob"))
I want to invoke the interceptor only for updateBlockBlob operatin
interceptSendToEndpoint("^(azure-blob:).+(operation=updateBlockBlob)").setHeader("fileName",simple("${file:onlyname.noext}")).convertBodyTo(File.class)
The above code works with interceptFrom().
I tried replacing the regular expression with wild card like azure* i.e interceptSendToEndpoint("azure*"). It did not work
Whats wrong with the above code? Is it because of recipientList?
Also what features does simple have to remove white space?
Is there a better way to generate blob names dynamically?
Here is the documentation from camel on interceptors.
http://camel.apache.org/intercept.html
interceptFrom that intercepts incoming Exchange in the route.
interceptSendToEndpoint that intercepts when an Exchange is about to
be sent to the given Endpoint.
So I suspect the Exchange is already formed and camel expects the url to be resolved.
So the header needs to be set before the exchange is created for the Azure end point.
I did the following. To set the header, I use the interceptFrom, and to convert the object into File I used the inteceptSendToEndPoint
interceptSendToEndpoint("^(azure-blob:).+(operation=updateBlockBlob)").convertBodyTo(File.class)
interceptFrom().setHeader("fileName",simple("${file:onlyname.noext}".replaceAll("[^a-zA-Z\d]")))
Managed to get rid of the whitespace too
I am building in invite/registration form for my site. The idea is that one user invites another user, which sends a code with a url to register with. The problem is that the code can have an encoded backslash in it. When that encoded backslash is processed in Angular, it seems to get decoded and ends up busting the routing.
http://localhost:54464/ang/register/owi0%2fCQCrjzBcwqEORVVHhrICIANGKxtxMJ2Kh91y%2bNhhB%2br06appZzEVPhpkP2C
becomes:
http://localhost:54464/ang/register/owi0/CQCrjzBcwqEORVVHhrICIANGKxtxMJ2Kh91y+NhhB+r06appZzEVPhpkP2C
How can I stop this behavior?
Try using a route like:
/register/*code
The code will contain the string with the slashes
source
It is typically used for path-like url arguments...but I don't see why this wouldn't work for your case.
I am sending a signup activation email containing a signup confirmation url with a confirmation token that points to an angular front end app:
...
Activate
...
Note that the token is a JWT and is fairly long.
This works find for most users, but for some clicking on the link takes them to https://domain/com only without the confirm-signup?token=...
It seems as though the mail client may be stripping off everything after the #, but I can't find any evidence of others having this problem, nor can I reproduce it.
My best guess so far is that some mail clients are seeing the # and somehow treating the trailing part as an internal anchor and stripping it...?
Has anyone else encountered this sort of problem? If so, have you found any solution short of replacing the whole mechanism with something else?
Some clients treat the hash-link just fine. Others don't. There's a conversation about Outlook being dirty about this here: Outlook strips URL hash from email
What we did to resolve this at our company is simply create a handler on our server that redirects. Your email link would become http://domain.com/email-link?url=https%3A%2F%2Fdomain.com%2F%23%2Fconfirm-signup%3Ftoken%3D1234 and your server side script would grab the query param url and immediately trigger a redirect.
You'd need to make sure that you find all links in your emails and replace them. Here's a PHP function for that, but you could do this in whatever backend language you're using. Regex here may be helpful at least.
function replaceLinks($html,$hash) {
return preg_replace_callback('/<a [^>]*href=[\"\']{1}(.+?)[\"\\\']{1}/', function($matches) use ($hash) {
return str_replace($matches[1],"http://domain.com/email-link?url=".rawurlencode($matches[1]),$matches[0]);
}, $html);
}
Yes I have encountered this issue before because of the #, I was trying to link to a anchor on a landingpage.. My solution ended up using a short.url service to "hide" the # from the html e.g. https://goo.gl/
Looks like you need percent encoding!
A lot of times when your href gets parsed (by angular in this case) it doesn't handle the special characters right, or strips them. Find your problem characters and replace them with %3F for ?, %26 for &, and %23 for #. The rest are in a chart in the link.
Once the encoded address hits the browser the url will be decoded in your url bar.
I am trying to invoke a REST service which has a special character in its path params. The rest url looks like,
rest\fetchDetails\[1,2,3]
I am just invoking it using $http like,
$http.get('rest\fetchDetails\[1,2,3]');
It is not working and when I debug it using firebug I can see the url is sent as
rest\fetchDetails\%5B1,2,3%5D
Is there any way to send '[' and ']' when invoking $http calls?
Solution 1:
Try with post request and pass params in Post Request.
Solution 2:
'[]' are special characters for URL. So it will be encoded.
If you want to decode this are your server code you can do it.
You are actually sending '[' and ']', however they are being url-encoded by the $http.get method. The url-encoding is necessary because the HTTP standard only allows some characters (alpha-numeric plus some) to be sent non-url-encoded.
BTW, I assume the backslashes () in your URL are regular slashes (/) since otherwise they too would be url-encoded.
Is there a way to make the Play! Framework ignore slashes and ? in parts of the URL?
Typically, if I have the following:
www.123.com/api/link/http:www.bla.com/?contenId=123&User=test
It won't work. In that case, what I would want to do is simply have the link in the last part of the URL in a String variable to save it. I suppose I can force the client to replace the / and ? by something else, but I would rather keep it simple.
My first thought was that maybe there is a way to configure the routing such that we have something like:
/api/link/{data}
where data would hold whatever remains of the URL. Can't find out how to do that though.
You can't have : / ? except your main URL. You should encode your parameter to append it to main URL. See URLEncoder for Java.
This is not a valid URL:
http://www.123.com/api/link/http://www.bla.com/?contenId=123&User=test
It must be:
http://www.123.com/api/link/http%3a%2f%2fwww.bla.com%2f%3fcontenId%3d123%26User%3dtest
Then you can pass it to {data} parameter and decode it in your handler method.