I have a use case where the RemoteReader plugin on our ImageResizer needs to handle the following url syntax:
http://imageresizer.local/remote/somedomain.com/segment/documentviewer/get_image.hml?img_name=filename.jpg
Out of the box, it seems that RemoteReader just looks to get_image.html to be the image, and doesn't utilize the query param to lookup an actual image. I understand how it would be hard for the plugin to know which params to send along with the request in order to get an image response.
My question is, will I need to fork the plugin to get this functionality, or is there a way I can force the plugin to send the entire url with params? Maybe I can utilize IIS url rewrites to help with this. Any direction would be appreciated.
You can't use the same querystring both for the remote server and for imageresizer. That would confuse both.
You'll need to base64 encode the remote URL (including querystring) and use the less human-friendly syntax accordingly.
Related
I currently have a bokeh_app.py file deployed and running absolutely fine
It is accessed by anyone in the network via URL HostName:PortNumber/bokeh_app
I want to add code which will make the app work via following URL
HostName:PortNumber/bokeh_app/?textboxvalue
And the page that would open is HostName:PortNumber/bokeh_app with updated Text box value to textboxvalue from the URL
What would be the changes I need to make to my code to achieve this, if possible. Please suggest
Accessing HTTP request arguments is covered in the documentation:
https://docs.bokeh.org/en/latest/docs/user_guide/server.html#accessing-the-http-request
I was trying to do some simple authorization for ameritrade's developer platform. I was attempting.
According to the platform, the Endpoint I need to access is is:
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri={uri}&client_id={client_id}}%40AMER.OAUTHAP
https://developer.tdameritrade.com/content/simple-auth-local-apps
When looking at the client_id, for the dev application, I was noticing that they may actually be referencing the Applications, Consumer Key instead? So i did just that, but when attempting to query the information, it returns: A third-party application may be attempting to make unauthorized access to your account. The reason why i think it is the consumer key, is listed at: https://developer.tdameritrade.com/content/getting-started
So I ended up doing something like:
from urllib.parse import urlencode, quote_plus
url = "https://auth.tdameritrade.com/auth?response_type=code&redirect_uri={uri}&client_id={client_id}}%40AMER.OAUTHAP".format(
uri=urlencode("http://localhost", quote_via=quote_plus),
client_id="JHBDFGJH45OOUDFHGJKSDBNG" #Sample
)
I dont think this is because I am currently in a different country currently, I think that something else is wrong here.
It doesnt follow through with it, but instead returns a 400 error with that information. Im not sure whats wrong though.
This happens when you copied the callback URI incorrectly. Imagine if this were a client application, and TD detected that the application is trying to send the user to a different URL than the app is configured with. If they send the callback request to that application, it will receive the token and gain full control over your account.
Have you double and triple checked that you're copying the callback URL correctly, protocol name, ports, and trailing slashes and everything? Also, consider using an API library instead of writing your own. You can find documentation about this specific error here.
I had this issue and I solved it using simply using http://127.0.0.1 on the call back URI of the App.
I then used below URL and it worked as expected.
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri=http%3A%2F%2F127.0.0.1&client_id={MyConsumerKey}%40AMER.OAUTHAP
Just in case anyone is still having this problem, make sure the callback URI is spelled EXACTLY the same as you specified when creating the app. I was having this problem because I set the callback on the TD developer website to "https://localhost/" and used "https://localhost" in the URL instead (missing the slash at the end). As soon as I added the slash at the end, it worked.
I found out that the issue is caused by the way the callback URL is set. It have to be exactly the same as the callback URL you have typed in at the apps details on the TD developer API page. I tried several permutations and indeed to get the authorization to work both have to be the same. eg. https or http.. end with '/' or does not, it matters. There is also no need to URL encode it.
We work on a product that is a series of components that could be installed on different CMSs and provide different services. We take a CMS agnostic approach and try to use the same code in all the CMSs as much as possible (we try to avoid using CMS API as much as we can).
Some part of the code needs to work with the current URL for some redirections so we use Request.Url.ToString() that is something that has worked fine in other environments but in Kentico instead of returning the current page we always get a reference to CMSPages/PortalTemplate.aspx with a querystring parameter aliasPath that holds the real URL. In addition to that, requesting the Template page using a browser gives you a 404 error.
Example:
Real URL (this works fine on a browser):
(1) https://www.customer.com/Membership/Questionnaire?Id=7207f9f9-7354-df11-88d9-005056837252
Request.Url.ToString() (this gives you a 404 error on a browser):
(2) https://www.customer.com/CMSPages/PortalTemplate.aspx?Id=7207f9f9-7354-df11-88d9-005056837252&aliaspath=/Membership/Questionnaire
I've noticed that the 404 error is thrown explicitly by the template code when invoked directly. Please see below code from Page_Init method of PortalTemplate.aspx.cs:
var resolvedTemplatePage = URLHelper.ResolveUrl(URLHelper.PortalTemplatePage);
if (RequestContext.RawURL.StartsWithCSafe(resolvedTemplatePage, true))
{
// Deny direct access to this page
RequestHelper.Respond404();
}
base.OnInit(e);
So, if I comment the above code out my redirection works fine ((2) resolves to (1)). I know it is not an elegant solution but since I cannot / don't want to use Kentico API is the only workaround I could find.
Note that I know that using Kentico API will solve the issue since I'm sure I will find an API method that will return the actual page. I'm trying to avoid that as much as possible.
Questions: Am I breaking something? Is there a better way of achieving what I trying to accomplish? Can you think on any good reason I shouldn't do what I'm doing (security, usability, etc)?
This is kind of a very broad question so I was not able to find any useful information on Kentico docs.
I'm testing all this on Kentico v8.2.50 which is the version one of my customers currently have.
Thanks in advance.
It's not really recommended to edit the source files of Kentico, as you may start to run into issues with future upgrades and also start to see some unexpected behaviour.
If you want to get the original URL sent to the server before Kentico's routing has done its work, you can use Page.Request.RawUrl. Using your above example, RawUrl would return a value of /Membership/Questionnaire?Id=7207f9f9-7354-df11-88d9-005056837252, whereas Url will return a Uri with a value of https://www.customer.com/CMSPages/PortalTemplate.aspx?Id=7207f9f9-7354-df11-88d9-005056837252&aliaspath=/Membership/Questionnaire (as you stated).
This should avoid needing to use the Kentico API and also avoid having to change a file that pretty much every request goes through when using the portal engine.
If you need to get the full URL to redirect to, you can use something like this:
var redirectUrl = Request.Url.GetLeftPart(UriPartial.Authority) + Request.RawUrl;
I'm trying to make a controller that delivers a random background image. I have a MVC route from /random-background.jpg to /MyController/RandomBackground, and it's returns File(backgroundImage, "image/jpeg"). This is working fine.
I've disabled the 404 plugin for all QueryStrings that ends with random-image, so the image is showing up. However, it won't take any parameters, such as random-background.jpg?width=200. &format=jpg doesn't have any effect either.
How do I get ImageResizer to accept this for a "real image"? Do I have to use ImageResizer.ImageJob? If so, I would love an example I can understand :)
ImageResizer V3 and earlier cannot 'post-process' the result of an MVC action or third-party HTTPHandler.
You will need to use one of the virtual providers plugins, use URL rewriting, or implement your own IVirtualImageProvider.
See the best practices guide for an explanation of 'why'.
I am having trouble invalidating CloudFront cached content with query string data.
For example, say I am trying to invalidate the following:
http://d114hh0cykwyb0.cloudfront.net/imagesizer.php?h=80&src=/images/foo.jpg
I use the AWS SDK to send the invalidation path, which is:
/imagesizer.php?h=80&src=/images/foo.jpg
I'll then go into the AWS Console->CloudFront->Distribution Settings->Invalidations
I see my new invalidation request. If I see the 'Details' on it, the Object Paths says:
/imagesizer.php%3Fh%3D80%26src%3D/images/foo.jpg
So the path has been encoded. However, after the invalidation has been Completed,
http://d114hh0cykwyb0.cloudfront.net/imagesizer.php?h=80&src=/images/foo.jpg
remains the same.
I also tried using the 'Create Invalidation' from within the AWS Console using the path:
/imagesizer.php?h=80&src=/images/foo.jpg
but I get an XML parse error (because the URL is not encoded).
Has anyone dealt with this kind of issue before? Were you able to find a solution?
Thanks!
a very easy way to use invalidation is the use of third party tools. Personally i use CloudBerry - > http://www.cloudberrylab.com/