Artifactory - custom base URL not working properly - artifactory

When I set the custom base url using the ui (http://localhost:8082/ui/admin/configuration/general), the only part that is considered is the ip address and protocol not the url path (http://<server_address>:<port>/<path>).
I notice that if I change the base url from http://localhost:8082 to http://test:8082 , requests done to http://localhost:8081 are directed to http://test:8082 . However, when I add a path http://localhost:8082/test/ the requests are redirected redirected to http://localhost:8082/ui instead of http://localhost:8082/test/ui
Is there a way to change this behaviour?
I'm using artifactory 7.2.1
-Edit-
I'm trying to setup a reserve proxy where the base path will be /app/artifactory. Therefore, all requests made to https://proxyhost/app/artifactory should be mapped to http://artifactoryhost:8082. However, I can't make the UI query internal resources appropriately because the base path is ignored, even with the flag X-JFrog-Override-Base-Url

This seems to imply that if you use the full URL, the base redirect does not occur
https://jfrog.com/knowledge-base/how-can-i-change-the-existing-base-url-of-artifactory/
Option 3 (Bypass the redirect):
Go to https://<ARTI_URL>/artifactory/webapp/#/login
The system will not redirect you if you use the full URL.

Related

On Demand TLS and Reverse Proxy Support for Custom Domains

I came into a situation today. Please share your expertise 🙏
I have a project (my-app.com) and one of the features is to generate a status page consisting of different endpoints.
Current Workflow
User login into the system
User creates a status page for one of his sites (e.g.google) and adds different endpoints and components to be included on that page.
System generates a link for a given status page.
For Example. my-app.com/status-page/google
But the user may want to see this page in his custom domain.
For Example. status.google.com
Since this is a custom domain, we need on-demand TLS functionality. For this feature, I used Caddy and is working fine. Caddy is running on our subdomain status.myserver.com and user's custom domain status.google.com has a CNAME to our subdomain status.myserver.com
Besides on-demand TLS, I am also required to do reverse proxy as
shown below.
For Example. status.google.com ->(CNAME)-> status.myserver.com ->(REVERSE_PROXY)-> my-app.com/status-page/google
But Caddy supports only protocol, host, and port format for reverse proxy like my-app.com but my requirement is to support reverse proxy for custom page my-app.com/status-page/google. How can I achieve this? Is there a better alternative to Caddy or a workaround with Caddy?
You're right, since you can't use a path in a reverse-proxy upstream URL, you'd have to do rewrite the request to include the path first, before initiating the reverse-proxy.
Additionally, upstream addresses cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported. You may use the rewrite directive should you need this.
So you should be able to use an internal caddy rewrite to add the /status-page/google path to every request. Then you can simply use my-app.com as your Caddy reverse-proxy upstream. This could look like this:
https:// {
rewrite * /status-page/google{path}?{query}
reverse_proxy http://my-app.com
}
You can find out more about all possible Caddy reverse_proxy upstream addresses you can use here: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#upstream-addresses
However, since you probably can't hard-code the name of the status page (/status-page/google) in your Caddyfile, you could set up a script (e.g. at /status-page) which takes a look at the requested URL, looks up the domain (e.g. status.google.com) in your database, and automatically outputs the correct status-page.

Nginx Rewrite URL Rule having special character(#) for Page section

I need help in rewriting the URL in nginx configuration which should work as below :
/products/#details to /produce/#items
but it is not working as # is creating a problem.
Note : # in the URL denotes the page section
e.g. www.test.com/products/#details should get redirected to www.test.com/produce/#items
This is impossible using nginx because browsers don't send hashtags (#details) to servers. So you cannot rewrite in nginx or any other web servers.
In other words, hashtags is available to the browser only, so you have to deal it with Javascript. The server can not read it.
https://www.rfc-editor.org/rfc/rfc2396#section-4
When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI.
There is no way to do this rewrite. The # and everything that precedes it will not be sent to the server, it is completely handled on the client side.

When to add http(s):// to website address

I'm trying to create a web browser using Cocoa and Swift. I have an NSTextField where the user can enter the website he wants to open and a WebView where the page requested is displayed. So far, to improve the user experience, I'm checking if the website entered by the user starts with http:// and add it if it doesn't. Well, it works for most of the cases but not every time, for example when the user wants to open a local web page or something like about:blank. How can I check if adding http:// is necessary and if I should rather add https:// instead of http://?
You need to be more precise in your categorization of what the user typed in.
Here are some examples and expected reactions:
www.google.com: should be translated into http://www.google.com
ftp://www.foo.com: Should not be modified. Same goes to file:// (local)
Barrack Obama: Should probably run a search engine
about:settings: Should open an internal page
So after you figure out these rules with all their exceptions, you can use a regex to find out what should be done.
As for HTTP vs. HTTPS - if the site supports HTTPS, you'll get a redirect response (307 Internal Redirect, 301 Moved Permanently etc) if you go to the HTTP link. So for example, if you try to navigate to http://www.facebook.com, you'll receive a 307 that will redirect you to https://www.facebook.com. In other words, it's up to the site to tell the browser that it has HTTPS (unless of course you navigated to HTTPS to begin with).
A simple and fairly accurate approach would simply be to look for the presence of a different schema. If the string starts with [SomeText]: before any slashes are encountered, it is likely intended to indicate a different schema such as about:, mailto:, file: or ftp:.
If you do not see a non-http schema, try resolving the URL as an HTTP URL by prepending http://.

Not able to use windows live api on local

HI,
I have issue in using Windows live API
Iam using asp.net, am not able to use the callback url on local
The signin link is working only if i provide live url, but i cant able to use local host.
Please help
It may help someone else also -
Please add following entry in hosts file (located at [%system drive%]\Windows\System32\drivers\etc)
127.0.0.1 www.example.com
#[Please replace example domain with your actual one]
Windows live server expects your return url to have http:// in it but chrome does not add it and IE do add it, I realized this after wasting sometime.
This should get you through testing api on your local machine.
Go and setup a dynamic dns and a name for your computer and make your tests this way.
For example you can setup on DynDns.com a name for your dynamic ip, and then setup your router with that name to automatic assign it (or do it manual from the pages), and then you can use this name, and not the localhost. Do not forget to open the port to your router so the other side can make requests.
Also on /windows/system32/drivers/etc/host you can also setup the same name to see your local host and make your tests and callbacks.
Your problem is that the callback address needs to be the same as the address you used to sign up with.
(In relation to your callback), from the documentation:
The domain name portion of the URL (for example, www.contoso.com) must
be the same as the one that you specified when you created your
application with Live Connect. The URL must use URL escape codes, such
as %20 for spaces, %3A for colons, and %2F for forward slashes.
So, based on what you have said, you are using localhost (which you can't). As #Aristos suggested, add an entry to /windows/system32/drivers/etc/host to the domain you have registered (eg www.contoso.com).
Use www.contoso.com instead of localhost to test.

Alternative to Response.Redirect to effect a subdomain

I have a site that is hosted in shared hosting environment. They use a wildcard subdomain setup and suggest using Response.Redirect to achieve the illusion of a subdomain.
Is there a way of doing this such that the "switch" takes place on the server rather than bouncing back down to the browser first?
Server.Transfer only works if I transfer to an actual resource. So redirecting from sub1.mydomain.com to www.mydomain.com/public/ does not work. I'd have to redirect to www.mydomain.com/public/mypage.aspx instead which i dont want to do.
To ensure that the "switch" takes place on the server, you could create a simple HTTP Module to intercept each request, inspect the requested URL and then forward them as needed . All your module has to do is handle the OnBeginRequest event, and then forward the request. In this way you could really have unlimited sub-domains.
Also might want add a blank host header, so that any requests for subdomains not listed get forwarded to the proper default website
If you aren't familiar with them, modules are very simple to create and work with.
Heres a link to a very similar implementation by Brendan Tompkins:
http://codebetter.com/blogs/brendan.tompkins/archive/2006/06/27/146875.aspx
You could also do some URL rewriting in the module should you need specific URL "look" behavior.

Resources