My Scenario: I am using API Management to front a logic app that is going to represent my on boarding process which involves calling my security service. To the outside world I want the consumer to pass me the user credential inside the Authorization Header.
My Problem Part 1: Logic Apps does not accept a Request with an Authorization Header
My Idea: Use a policy inside API Management to change the name of Authorization Header e.g. User-Agent which can be accepted by Logic Apps
My Problem Part 2: I cannot find anything that will simply allow me to change the name, loads on changing values but not the name. I have even tried deleting the Authorization Header inside Inbound Processing and recreating it with the new header name but you cannot save a policy that uses a value from a deleted property.
Any help would be greatly appreciated
Try adding a new header first, and removing source one later:
<set-header name="X-Authorization" exist-action="override">
<value>#(context.Request.Headers.GetValueOrDefault("Authorization", ""))</value>
<set-header>
<set-header name="Authorization" exist-action="delete" />
Related
Hey I was just wondering can you write code in a React application that sends a POST request to the Azure API but specifically create a backlog? I can see you can perform a GET request but haven't seen anything about POST
I have been on their documentation and it covers GET but I do not see anything about POST
AFAIK, you cannot create any backlog instances at all. Since there is no support in doing this via the WebGUI, I would assume that there is also no REST-API call for it.
From a logical (or agile) point of view, having backlog instances makes no sense as well: Either a work item (task / user story /... you name it) is part of a sprint or it is placed in the backlog.
This is also the way DevOps handles your work items: If you create a new work item it is placed in the backlog (single instance) by default. When adding it to a sprint, it will be moved out of the backlog.
TL;DR: I guess it is not possible on intention.
after checking in azure devops, if you are about create a backlog page in boards for workitems, then you could not separately create a single backlog page.
You need to create a new team and the backlog for the team will be generated automatically.
You could refer to this doc for team creation rest api.
My api is below.
post https://dev.azure.com/<orgname>/_apis/projects/<projectID>/teams?api-version=5.1-preview.3
request body
{
"description":"",
"projectId":"<projectID>",
"name":"<teamname>",
"identity":
{
"customDisplayName":"<teamname>"
}
}
Sorry if this might be a bit of a trivial question, but I wanna be sure and couldn't exactly find a definitive answer online.
I am writing a small app that uses Mapbox, and I am using react-map-gl for it. They require the access token on the client side, so they suggest using an environment variable. My question is would it be okay to simply create a .env file in the front-end folder and put the variable there?
Thanks!
You can't get away from revealing API keys on the front end. If someone wants to dig around in your source code, they will find them.
However, you should always configure any API key that is visible on the Internet to be restricted to specific referrers, i.e. the domain of your website.
Usually this is done during creation of an API key through your provider's dashboard.
For Mapbox, you can read the documentation on restricting API tokens here. It states:
You can make your access tokens for web maps more secure by adding URL restrictions. When you add a URL restriction to a token, that token will only work for requests that originate from the URLs you specify. Tokens without restrictions will work for requests originating from any URL.
(emphasis my own)
They require the access token on the client side, so they suggest using an environment variable. My question is would it be okay to simply create a .env file in the front-end folder and put the variable there?
There are two reasons one uses environment variables in front-end development:
As a convenience, to keep environment-specific configuration removed from source code.
To keep sensitive information out of source code. You shouldn't commit API tokens or other similarly sensitive details to your version control.
Using environment variables in front-end code will not to keep their values secret from the end user. Whatever the value of an environment variable is at build time will be visible in the compiled output.
I have an application written in angularjs and a dropwizard backend. All API calls are ajax, with the exception of file downloads, which is done by performing a redirect to a standard GET request.
All API calls are secured through a token which is passed as a Token header. We use SSL for all APIs.
The download GET request works but I'm having a hard time figuring out how to secure it. I have no way of setting a custom header, which is required to pass the token. So theoretically, I'm left with two options, clearly none of them acceptable: 1. Pass the token as one the GET parameters 2. Leave the download unsecured.
Any ideas how to secure file download?
Putting a secret token in a URL query parameter isn't great because URL tend to be leakable, for example through history/logging/referrers. There are ways to mitigate this: for example you could have the server side issue a download token that is only good for one use or for a limited amount of time. Or the client could pass a time-limited token created using a signature over the secret token that the server side could verify.
Alternatively you could, just for this one interface (eg path-limited, quitckly-expiring) put the token in a cookie.
Another approach is to download the whole file through AJAX, thus allowing you to set the header as normal. Then you have to present the content as a downloadable local resource, which requires a cocktail of browser-specific hacks (eg using data: or filesystem: URLs, and potentially links with the download attribute). Given the complication this isn't usually worth bothering with, especially if the file is very large which may present further storage constraints.
in the official trigger.io docs there seems to be no provision for custom http headers when it comes to the forge.file module. I need this so I can download files behind an http authentication scheme. This seems like an easy thing to add, if support is not already there.
any workarounds? any chance of a quick fix in the next update? I know I could use forge.request instead, but I'd like to keep a local copy (saveURL).
thanks
Unfortunately the file module just uses simple "download url" methods rather than a full HTTP request library, which makes it a fairly big task to add support for custom headers.
I've added a task to our backlog for this, but I don't have a timeframe for it being added.
Currently on iOS you can do basic auth by using urls in the form http://user:password#url.com in case that helps.
Maybe to avoid this you can configure your server differently, or have a proxy server in front that allows you to pass authentication details as get parameters?
Right now I've got Spring Security protecting an application using basic authentication. The user details are coming from a JDBC source. If the database goes down, the internals of the user loading mechanism will throw a DataAccessException. The default authentication provider class, DaoAuthenticationProvider, catches the exception and maps it back to an AuthenticationServiceException. The end result of such a mapping is that the browser/client receives HTTP code 401.
What I want to do is to handle database unavailability in a different way. At the very least, I want this to be handled by responding with HTTP 503 but I would prefer if it redirected to an error page. How can I achieve this?
EDIT: Ritesh's solution was partially correct. The missing steps apart from implementing your own Basic entry point is to also use v3.0.3 of the security schema so that the <http-basic/> element has the entry-point-ref attribute. If you don't use this special attribute, the default Basic filter will always use its own Basic entry point implementation.
The BasicAuthenticationEntryPoint sends 401 for AuthenticationException. You can create your own custom entry point to handle AuthenticationServiceException and send out 503.
Other option is not to do anything in entry point and use SimpleMappingExceptionResolver and/or implement your own HandlerExceptionResolver.