When using a Variable named xxxx_apiKey in airflow it masks the value of the variable in the UI as expected. But when we are trying to use that variable in a DAG the value returned from:
Variable.get('xxxx_apiKey')
returns the masked value ******.
Is there a method parameter to retrieve the value unmasked?
The method you're calling should decrypt your secret when calling it. In my opinion, you've rewritten by mistake the variable and the real content now contains stars. This may happen through the web interface. Try storing again the content of this variable and see if it works now.
Related
During the recv subroutine I am currently changing my backend to another backend to handle the request, I need to declare a variable that will hold the value for the first/original backend that it was set to, so that when the request is restarted, I can then assign the backend back to this.
I can't just use the name for the backend and simply assign it back as I need it to be dynamic, storing it in a variable seems like the simplest solution but I can't seem to find any information on how this can be achieved through subroutines/ restarts.
If not possible are there any other solutions I could try to achieve this? Probably not possible from what I understand but even the ability to access an array of the backends defined and picking the first one would suffice, I just cant rely on naming the backend to assign it back.
Unfortunately it isn't possible to declare a variable as a BACKEND type (which is what req.backend returns).
See this 'Fastly Fiddle' example that demonstrates you'll get a compiler error of:
Expected variable type, one of: BOOL, INTEGER, FLOAT, TIME, RTIME, IP or STRING
There also isn't any way to get a list of available backends via VCL either.
Additionally you would need to hardcode the backend value (i.e. you need to explicitly know what backends are defined from the VCL perspective) as trying to store a backend into a header or variable will convert it to a STRING type representation (such as 6kLtu7NicmMs0DtKsuite9--F_origin_0).
This means even if you were able to parse the actual F_origin_0 backend from the string you wouldn't be able to assign it as a value to req.backend as that expects the value to be of type BACKEND (and VCL doesn't provide a way, AFAIK, to convert a string into that type).
When using an endpoint I am able to get the request done successfully and retrieve the response as well but when I use the variable in my endpoint for example: {{abc}}/api/user/id it gives status 404 not found and I have specified the variable in the collection "abc"
so not sure why is this issue is coming. Why the variable is not recognizable?
Thanks in advance.
Do you have any environment variable or local variable or data variable with same name ? These have more preference than collection so if you have same variable name then this values will over ride the collection variable value
https://learning.postman.com/docs/sending-requests/variables/#variable-scopes
In postman precedence is from down to bottom and scope is from top to bottom
Scope:
Meaning if you have global variable defined then it will be visible for all collections and environment variable will be visible only for that particular environment.
Precedence
if you have a variable with same name defined in both environment and collection then the value will be taken from environment. as precedence is collection < environment
I would like to be able to generically access a list\dictionary of parameters from within an action. I know its possible to do this from within an ActionFilter by using:
ActionExecutingContext.ActionDescriptor.Parameters
But, I can't figure out a way to access that same list from within the action itself.
Backstory:
The end goal is for all of my actions to call the same function. The function will accept a stored proc name, and a list of parameters, then execute the stored proc using the supplied parameters. I have created each action so that the actions parameters are the same name\type as the stored proc parameters. Using this setup, I want to be able to just send the list of parameters associated with the action to a single generic call.
I have tried using:
HttpContext.Request.Query
But, that won't work, because I could have some action parameters that aren't required and have a default, these don't show up in the http query, and I still need them to be passed into my generic function.
"ModelState" is what I was looking for, it has everything I need, including the default values of the parameters that weren't in the query string.
Is it considered bad practice to pass whole objects to meteor methods and should I stick to just passing the ID, and then using the passed Id to fetch the document from within the meteor method instead?
The main consideration here is security: if your method is expecting to be passed an object, a Meteor-savvy user can call it from the console, passing any object of their choosing as the argument, whether it's in your DB or not, thereby bypassing any DB schema/validation you have set up. In order to avoid that, you need to be looking the object up in the DB in your server-side method code, which rather defeats the point of passing in the whole object rather than just the id in the first place. So, in summary, pass the id rather than the object.
If the user should be able to call your method with an arbitrary object, then I'd argue that you absolutely should be passing the whole object rather than just the id as otherwise you're necessitating storing a document in the database purely so that you can call a method on it, which is ugly. However, I think that would be a fairly unusual situation.
In a legacy MFC CHttpServer based web server, we have a command parsing map something like this:
BEGIN_PARSE_MAP(MyHttpServer, CHttpServer)
ON_PARSE_COMMAND(MyPage, MyHttpServer, ITS_I4 ITS_I4 ITS_I4 ITS_I4 ITS_PSTR ITS_PSTR ITS_PSTR ITS_I4)
ON_PARSE_COMMAND_PARAMS("intParam1=11 intParam2=12 intParam3=13 intParam4=14 strParam5=s5 strParam6=s6 strParam7=s7 intParam8=18")
END_PARSE_MAP(MyHttpServer)
This defines a page accessible at http://host/path/dllname.dll?MyPage that accepts up to 8 parameters named intParam1, intParam2, intParam3, intParam4, strParam5, strParam6, strParam7, and intParam8.
The calling applications can invoke the page with the parameters in a named fashion like this:
http://host/path/dllname.dll?MyPage?intParam4=32&strParam7=somestring
But the way MFC command parsing maps work, they can also call it with unnamed parameters as long as they are provided in the order defined by the map:
http://host/path/dllname.dll?MyPage?21&22&23&24&string5&string6&string7&28
I would like to replace this old code with an ASP.Net page, but we have existing calling applications that will not be changed that invoke the page using both styles of parameter passing, named and unnamed.
I can easily manage the necessary URL rewriting to allow an ASP.Net page to respond to the URL as given above, replacing the path/dllname.dll? MyPage portion with the path to an .aspx page or .ashx handler.
The problem comes in when trying to handle the unnamed parameters in an equivalent fashion to the old MFC parameter parser. Request.QueryString treats all the unnamed parameters as being named with null and Request.QueryString[null] returns a comma-separated list of the values. This is pretty close to workable, but should one of the parameters actually contain a comma, this encoding falls apart because the extra comma is not escaped and splitting the string on the commas will end up with too many parameters.
In classic ASP, I believe Request.QueryString(...) returned a collection of all the parameters that were identically named. There seems to be no equivalent to that in ASP.Net that I can find.
As a secondary issue, the MFC command parsing map had some pretty convoluted logic for dealing with a mixture of named and unnamed parameters. Although the callers of the page in question will not be mixing their usage in this way, I am interested in perhaps duplicating the logic for completeness sake. Can anyone confirm that MFC's behavior was essentially the following?
Process all parameters in the URL from left to right, using & as separator.
If named (has an equal sign), apply the value to the parameter with the corresponding name, regardless of its position. If that parameter already assigned a value, error.
If unnamed, apply the value to the parameter at the nth position in the command parsing map, where n is the number of already processed unnamed parameters plus 1. If that parameter was already assigned a value, error.
Apply default values from command parsing map to any parameters not assigned above
If any parameters from command parsing map have not been assigned a value, error.
One more interesting note, it appears that Request.QueryString.ToString() will nearly reconstitute the original parameters on the URL, but it always moves the parameters with identical names to be together, including the unnamed parameters I am concerned with here.
Not sure if solves your problem, but you could try using Request.PathInfo. This will give you everything entered after the page, which you could then parse manually using something like a regex.
For example, if you had the URL:
http://host/path/dllname.dll?MyPage?21&22&23&24&string5&string6&string7&28
The Request.PathInfo property would return:
?MyPage?21&22&23&24&string5&string6&string7&28
Processing this into a set of values that you can work with could also be problematic as you've got both named and un-named parameters, but this should be achievable using regular expressions and/or splitting the string.
I found that Request.QueryString has a GetValues() method. This returns an array of strings and solves the problem of a comma being embedded within one of the values. It'll be even easier to use than having to split the results of Request.QueryString[null].
I still have a bit of work to use this to implement an MFC-like mapping of URL parameters that handles both named and unnamed parameters.