Basically the use-case is this:
Open a website > receiving the content from other website (and interacting with it like if it was the original link), so not just html but being able to log in, etc.
The thing is: I want to use my server as a bridge/proxy. (Like https://www.croxyproxy.com/ or https://www.proxysite.com/). For example: let's say I go to https://whatismyipaddress.com/, instead of seeing my real ip, I would like to see my server's ip.
How can I accomplish that? Please help me clarify the approach (and what stack can I use). I'm totally lost after googling a lot, so far I've found this:
http://greim.github.io/hoxy/
https://github.com/Athlon1600/php-proxy-app
https://github.com/mswjs/http-middleware
Thanks a lot in advance.
I have configured my Liferay 7 site with a terms of use web content document. It works perfectly when new users log in for the first time.
However, I need to be able to provide a link to review the terms of use. The only thing I see is in the Liferay Portal struts-config.xml file, which is "/portal/terms_of_use". But this link appended to my hostname is not working. I get a "Not Found" error page ("The requested resource could not be found.").
Am I using the wrong URL? I've tried searching for what the URL would be and have not found anything, which is surprising since I would think this is a common requirement.
With the routing of web-stuff to OSGi bundles, there's no longer any top-level URL that can be specified this way (there may never have been one). However, there is a way to get to it:
http://localhost:8080/c/portal/terms_of_use requires login, but results in the (in my case unconfigured) terms of use. The /c within the URL targets struts (and maybe something else - the /portal within targets a certain bundle (portal-web in this case)
We are developing a command line tool that relies on a third party Cloud Object Storage SDK, so we cannot modify the request address directly (unless we remade our own SDK based on the official one which is wrong at so many levels). We noticed the IPs resolved by our clients can often be problematic due to their geolocation or DNS provider. So we want to be able to create a "custom host" file if you would say and embed it into the command line tool (npm global module). We look up the DNS documentation and doesn't seem to find relevant information. https://nodejs.org/api/dns.html
So basically what we try to do is that one person may resolve google.com to 8.7.198.46, and another person may resolve google.com to 74.125.200.139, instead of letting the DNS do the job we want to force all hostname google.com to resolve to a specific IP (let's say 88.88.88.88). How will I be able to do this with Node.js (OR perhaps with the help of an additional shell script)?
It's possible to generate a link to raw content of the file in GitHub, is it possible to do with VSTS/DevOps?
Even after reading the existing answers, I still struggled with this a bit, so I wanted to leave a bit more of a thorough response.
As others have said, the pattern is (query split onto separate lines for ease of reading):
https://dev.azure.com/{{organization}}/{{project}}/_apis/sourceProviders/{{providerName}}/filecontents
?repository={{repository}}
&path={{path}}
&commitOrBranch={{commitOrBranch}}
&api-version=5.0-preview.1
But how do you find the values for these variables? If you go into your Azure DevOps, choose Repos > Files from the left navigation, and select a particular file, your current url should look something like this:
https://dev.azure.com/{{organization}}/{{project}}/_git/{{repository}}?path=%2Fpackage.json
You should use those values for organization, project, and repository. For path, you'll see an HTTP encoded version of the unix file path. %2F is the HTTP encoding for /, so that path is actually just /package.json (a tool like Postman will do that encoding for you).
Commit or branch is pretty self explanatory; you either know what you want for this value or you should use master. I have "hard-coded" the api version in the above url because that's what the documentation currently points to.
For the last variable, you need providerName. In short, you should probably use TfsGit. I got this value from looking through the list of source providers and looking for one with a value of true for supportedCapabilities.queryFileContents.
However, if you just request this URL you'll get a "203 Non-Authoritative Information" response back because you still need to authenticate yourself. Referring again to the same documentation, it says to use Basic auth with any value for the username and a personal access token for the password. You can create a personal access token at https://dev.azure.com/{{organization}}/_usersSettings/tokens; ensure that it has the Token Administration - Read & Manage permission.
If you're unfamiliar with this sort of thing, again Postman is super helpful with getting these requests working before you get into the code.
So if you have a repository with a src directory at the root, and you're trying to get the file contents of src/package.json, your URL should look something like:
https://dev.azure.com/{{organization}}/{{project}}/_apis/sourceProviders/TfsGit/filecontents?repository={{repository}}&commitOrBranch=master&api-version={{api-version}}&path=src%2Fpackage.json
And don't forget the basic auth!
Sure, here's the rests call needed:
GET https://feeds.dev.azure.com/{organization}/_apis/packaging/Feeds/{feedId}/packages/{packageId}?includeAllVersions={includeAllVersions}&includeUrls={includeUrls}&isListed={isListed}&isRelease={isRelease}&includeDeleted={includeDeleted}&includeDescription={includeDescription}&api-version=5.0-preview.1
https://learn.microsoft.com/en-us/rest/api/azure/devops/artifacts/artifact%20%20details/get%20package?view=azure-devops-rest-5.0#package
I was able to get the raw contents of a file using this URL.
GET https://dev.azure.com/{organization}/{project}/_apis/sourceProviders/{providerName}/filecontents?serviceEndpointId={serviceEndpointId}&repository={repository}&commitOrBranch={commitOrBranch}&path={path}&api-version=5.0-preview.1
I got this from here.
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/source%20providers/get%20file%20contents?view=azure-devops-rest-5.0
You can obtain the raw URL using chrome.
Turn on Developer tools and view the Network tab.
Navigate to view the required file in the DevOps portal (Content panel). Once the content view is visible check the network tab again and find the URL which starts with "Items?Path", this is json response which contains the required "url:" element.
Drag the filename from the attachments windows and drop it in to any other MS application to get the raw URL or linked filename.
Most answers address this well, but in context of a public repo with anonymous access the api is different. Here is the one that works in such a scenario:
https://dev.azure.com/{{your_user_name}}/{{project_name}}/_apis/git/repositories/{{repo_name_encoded}}/items?scopePath={{path_to_your_file}}&api-version=6.0
This is the exact equivalent of the "raw" url provided by Github.
Another way that may be helpful if you want to quickly get the raw URL for a specific file that you are browsing:
install the browser extension named "Undisposition"
from the dot menu (top right) choose "Download": the file will open in a new browser tab from which you can copy the URL
(edit: unfortunately this will only work for file types that the browser knows how to open, otherwise it will still offer to download it...)
I am fairly new to this and had an issue accessing a raw file in an Azure DevOps Repo. It's straightforward in Github.
I wanted to download a file in CMD and BASH using Curl.
First I browsed to the file contents in the browser make a note of the bold sections:
https://dev.azure.com/**myOrg**/_git/**myProjectName**?path=%2F**MyFileName.ps1**
I then constructed the URL similar to what #Zach posted above.
https://dev.azure.com/**myOrg**/**myProjectName**/_apis/sourceProviders/TfsGit/filecontents?repository=**myProjectName**&commitOrBranch=**master**&api-version=5.0-preview.1&path=%2F**MyFileName.ps1**
Now when I paste the above URL in the browser it displays the content in RAW form similar to GitHub.
The difference was I had to setup a PAT (Personal Access Token) in My Azure DevOps account then authenticate the URL in DOS/BASH example below:
curl -u "<username>:<password>" "https://dev.azure.com/myOrg/myProjectName/_apis/sourceProviders/TfsGit/filecontents?repository=myProjectName&commitOrBranch=master&api-version=5.0-preview.1&path=%2FMyFileName.ps1" -# -L -o MyFileName.ps1
temp:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community)";"State of Maine";2);
temp1:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community)";"State of Maine";3);
temp2:=#DbLookup("Notes":"NoCache";"ARRoW/SSS":"sss/sssProj.nsf";"(Lookup for Community POC)";"State of Maine";4);
#If(#IsError(temp)|#IsError(temp1)|#IsError(temp2);"Error";temp + " " + temp1 + " " + temp2)
Hi this works on Lotus Notes Client but doesn't work on web Any help is welcome thanks in advance!
There are typically three types of root causes for something like this.
One type of problem is server trust. This only applies if there are two servers involved. I.e., the web server is ServerX/SSS and the code is trying to access ARRoW/SSS. You need to review ARRoW/SSS's server document and check whether "ServerX/SSS" is listed in the field for "Trusted servers". (Also note that if this is a really, really old version of Domino - before version 6 if I recall correctly - then the trusted servers feature is not there and you cannot make cross-server calls to #DbLookup in web code.)
The second type of problem is that the server where the code is running can not resolve the name of the server where the database lives. The code is accessing server ARRoW/SSS, but you haven't said whether ARRoW/SSS is the actual web server, so let's look at both cases.
Assuming that it is all happening on one server, there can still be a name resolution problem because of the way the formula is coded. Try specifying "":"sss/sssProj.nsf" instead of "ARRoW/SSS":"sss/sssProj.nsf". If that fixes your problem, great! But it means that you still have a problem either in your server document or with the DNS configuration on your Domino server and you should address that. You should probably continue with the troubleshooting that I give in the next paragraph. Just bear in mind that everything I say there is true even if ServerX/SSS is really the same as Arrow/SSS.
If the code is running on web server ServerX/SSS, then you need to make sure that ServerX can connect to ARRoW/SSS. The easiest way to do this is to bring up the console for ServerX and enter the command 'trace ARRoW/SSS'. If it fails, check the server documents and/or connection documents for correct IP addresses or host names, and open a command window on the server and try a ping using the exact information in the server documents. If it fails, you have a networking issue. One of the underlying causes I've seen for a problem like this is that there is no connection document (because the servers are in the same named network, but neither the IP address nor the fully-qualified host name is entered in the networks table in the server document, so Domino just asks DNS to resolve the common name 'ARRow' - but the DNS configuration on the web server does not include a default search path so the name is not resolved. But you need to check everything until you can get a 'trace' command to succeed.
The third type of problem is Access Control. This is a broad category that comes down to the fact that the identity that the code is running under either does not have access to the server ARRoW/SSS, the database sss/sssProj.nsf, the view (Lookup for Community)" or the document(s) with the key "State of Maine". There are a lot of things to check. If the code is running in a field formula, the identity is that of the user, and if the same user does not get the error through the web client then you need to look at the database properties for sss/sssProj.nsf and check the maximum web access level. If the code is running as an agent, you need to check the agent properties to determine what identity the agent is running under, and then review everything: the security settings in the server document, the database ACL, restrictions on the view, and reader names fields in the documents.