I'm attempting to incorporate subroutines in Microsoft Flow, which seems to be done by creating a flow called via HTTP by another Flow per posts online. Creating a simple flow that I can call from Postman works great. The problem occurs when I call it from my main flow.
It wanted an API version, so I set the query api-version to 2016-10-01
Now, when it runs, it gives the error
"code": "DirectApiAuthorizationRequired",
"message": "The request must be authenticated only by Shared Access scheme."
Again, the called flow works fine from Postman. It's when called from Flow that it gives the error. All the steps I see online are for Logic App or other tools. Suggestions?
I discovered that when I was recopying the URL, that I had lost the authentication information has it had been moved to Queries in my REST client, so the code was not actually authenticating. So, if anyone else has this issue, copy the URL from the original source!
Related
I ran OWASP ZAP and the tool threw up a high vulnerability for possible SQL injection issue. Although we know for sure we do not use any sql databases as part of our application stack, I poked around and have have a few questions.
The payload that detected this “vulnerability” was as below:
https://demo.meteor.app/sockjs/info?cb=n6_udji55a+AND+7843%3D8180--+UFVTsdsds
Running this on the browser, I get a response:
{"websocket":true,"origins":["*:*"],"cookie_needed":false,"entropy":3440653497}
I am able to go ahead and make any sort of manipulations to what comes after the cb= part and I still get the same response. I believe this is what has tricked the tool to flag this as vulnerability - where in it injected a -- with some characters and still managed to get a proper response.
How can I make sure that changing the URL parameter to something that does not exist, returns a 404 or a forbidden message?
Along the same lines, when I try to do a GET (or simply a browser call) for:
https://demo.meteor.app/packages/accounts-base.js?hash=13rhofnjarehwofnje
I get the auto generated JS file for accounts-base.js.
If I manipulate the hash= value, I still get the same accounts-base.js file rendered. Shouldn’t it render a 404? If not, what role does the hash play? I feel that the vulnerability testing tool is flagging such URL based manipulations wrongly and ascertaining that there is some vulnerability with the application.
Summarizing my question:
How do I make sure that manipulating the URL gives me a 404 or at the very least, forbidden message instead of always giving a 200:ok in a meteor application?
I was developing Instant triggers for my Integromat app. I finished 2 of them, and when I started the third one, all webhooks stopped working.
I wrote a mail to the support of about the situation and received the answer:
We can see in logs that webhooks fired from our end but your system
returned us error 400 - it means that webhook works on our side but
was not properly received on your servers side.
So why Integromat can answer 400 code? Is it a bug or my mistake? From that moment, I have tried with the new account, but the issue is still there.
Any suggestions?
Judging by the response you received from the 3rd-party tech support, there's an error somewhere in your webhook code.
The first thing I'd check is of course the code directly inside your webhook's Communication tab, but also, if this code is calling any IML functions you wrote, you'll need to double-check that the IML code is not failing as well.
You could create an IML test using the Integromat Apps SDK VS Code plugin to simulate the function call with incoming JSON data (according to the documentation of the service you are implementing) and see if this call results in some kind of an unexpected error.
I've had Application Insights set up on my ASP.NET project for a couple months with no issues. I use Custom Events for logging certain events.
Recently, I tried to add a Custom Event after a user has authenticated in order to track the login behavior. My custom event DOES log to application insights debug session. I know this because I can see it in the telemetry when paused on a breakpoint just after the event.
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
I cannot understand what the issue is. Does anyone familiar have any (application) insights? I couldn't help myself ;)
There are some things to check:
are you logging to one resource (iKey) and searching on another? (a lot of people send data to one resource in dev/debug and a different resource in release/prod environments. so make sure you're sending to the place you expect, and searching the place you expect.
is the data actually going out successfully? you may need to use fiddler or some other tool to watch your outbound http for calls to dc.services.visualstudio.com. It could somehow be the case that there's something wrong with the data you're sending, or maybe you're getting capped or throttled by the service. If that's the case, the outbound requests will have responses other than 200, and will generally tell you the reason it didn't accept any items that it rejected.
if the data is getting successfully sent and is going where you expect it to go, there might just be a delay in backend processing. you can always check aka.ms/aistatus to see if there are any current issues with the service.
I am confused, however, by what you mean when you say
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
What do you mean "it just disappears" ? if you see it in the output window, then the SDK saw it, and it will get sent, precluding any of the above 3 items. Where is it "disappearing" from? unless you clear the output window, it's never gone from there. If you're talking about the VS search tools that show data sent by the AI SDK during debug, that tool currently has a cap of the most recent 250 items that have occurred during the debug session.
I am using Spring MVC to create RESTful endpoints. I am using spring-test-mvc to test them at the unit/integration test level. I am now coming across this team's first attempt at implementing an endpoint using DELETE. This means the container needs to be setup to allow for DELETE (PUT will come shortly after). My research took me here:
http://www.codereye.com/2010/12/configure-tomcat-to-accept-http-put.html
I am technically using JBoss, but I have a feeling a Tomcat write-up will do just fine. Anyway, my problem is not at the container level.
I am trying to create a unit test to verify the most basic of 404. Let's say you try to delete a user calling /users/{id}. My test passes an invalid id, and I expect a 404 to return. It gives a 405. This makes sense when DELETE is not supported. Following the instructions in the link above, I should add some entries to the web.xml. I did so in main and test. Both still gave me the 405.
How would I setup spring-test-mvc to grab these new http-method types out of the web.xml or some other location? My research hasn't come up with anything other than DELETE isn't initially supported.
Thanks
Dustin
Spring-test-mvc does support DELETE(and PUT), I have used it with a DELETE based method, it is true that you need to add HiddenHttpMethodFilter filter in web.xml for DELETE http method to work within your application, however spring-test-mvc does not look at the filter, it works from DispatcherServlet down, here is one of the samples that works for me:
mockMvc.perform(delete("/members/1").contentType(MediaType.APPLICATION_JSON))
.andExpect(status().isOk());
The error you are seeing I feel could be more related to the content-type or accept headers, that is where I have seen 405 being returned, you may be able to change your log level to debug or trace and see what else shows up.
I'm using the Organization Service URI to upload documents to our SharePoint site from notes and attachments. I'm using the code found here and all is working apart from where i set the organizationURI. I get an error of "metadata contains a reference that cannot be resolved". I have tried retyping the link in and everything i can think of but i always get this error.
The strange thing is that this was working a couple of days ago just fine, but when i tried it the next morning it refused to work and now wont do anything at all. Before this error i have now i was getting an error saying that the URI scheme is not valid. I don't know what could have caused this to stop working but i've tried all i can think of and need some help.
Thanks
EDIT: The error message has changed to "A proxy type with the name account has been defined by another assembly". Still not sure what it means, but i'm hoping this might be easier to fix
I'm not sure if this is the actual fix for this problem but i tried this and it seemed to work. So either it is the answer or i was just lucky and something else changed too, but anyway...
What i did was to change the way that i was connecting to the organization service. Before i was using user credentials, organization URI and home realm uri together to get the OrganisationServiceProxy in the form of OrganizationServiceProxy orgService = new OrganizationServiceProxy(organizationUri, homeRealmUri, cred, null);.
Now i'm using a longer method of first setting the discovery service with user credentials. Then together with them i set the discovery service proxy, which is then authenticated. Then i simply use a RetrueveOrganizationRequest / Response to get the organization service which i can then use in place of the original.
Hope that makes sense to people but if anyone wants i can put some code up showing what i did.