We Keep Coding

How to detect API call from Zapier?

Is there any way to detect API call from Zapier to my app?
I've created two zaps on Zapier. Creating tasks from Wrike to MyApp and vice versa.
I got infinite loop, because when I create task on Wrike it is automatically created on MyApp. But than Zapier detects new task on MyApp and creates new one (same task) in Wrike and so on.
I was thinking to add new field in task object (createdFromZapier) and filter by that field, but is there any other way to handle this?

Here is answer from Zapier team:
There isn't a great way to do this — at best, you could set the User Agent header within your developer integration and then inspect the header on your API server side to detect when a request is coming from Zapier.
We have a help guide on avoiding Zap loops at https://zapier.com/help/troubleshoot/behavior/zap-is-stuck-in-a-loop which might help.

What would a conditional privilege implementation look like using Spring Security?

What I mean by 'conditional' privileges is, for example: Say we have Event e. The user who CREATED Event e should be able to delete Event e and invite additional users to Event e, but only that user.
From tutorials I've seen, permissions and roles seem static, for example:
Doctor has a role doctor, with permissions x, y and z, but that is it...pretty static.
Is there a simple way to conditionally manage permissions with Spring Security?
Or would this be something better suited for the front-end? For example, the view would show a 'delete event' button only if the resource data for that particular Event confirms that the Event creator's ID is in fact the same ID stored in session memory/keychain/whatever for the currently logged in user, type of thing.
Thanks

First of all,
Or would this be something better suited for the front-end?
...show a 'delete event' button only if...
NO. Not as a reliable line of defence, no.
Well that probably depends on a tech stack, architecture etc, but as a rule of thumb, you shouldn't do it. I didn't write servlets/jsp, but I used spring security in a rich client (swing) application and even though we had all the control (I mean, we could guarantee that user cannot access some function no other way than clicking a button), we secured our models, not the gui.
You shouldn't be able to call Entity#delete no matter how you call it - via button click event or calling it directly in a test. In case of web application, imagine you don't display a button, but an attacker knows that button leads to example.com/entity?action=delete URL or something like that, he could access it directly even if you don't render the button.
With regard to the main question, spring security, roughly speaking, has two parts: RBAC and ACL. What you need seems to be the ACL part. Read some howtos and articles about domain security, it's a pretty complex stuff, but it can be suited for your needs for sure (with some effort, of course). What you described in a first paragraph may be achieved easily because every object has it's owner and it can be exploited.
Also, here's a good advice.
Edit: just to clear things up for future visitors. Point was: there should be some logic on the front-end, but it must not be the only security logic. Of course there's no need to clutter UI with buttons leading to functions you can't access.

How to implement flow control in Play?

We are trying to implement some flow control in Play, kind of a wizard with several steps. What is the best practice to do it in Play?
Requirements we have:
Should allow multi-step flows, like step1 -> step2 -> step3 -> step4 -> finish
Should be able to change order or steps depending on context, so if user selects a checkbox on step2, flow should be step1 -> step2 -> warningStep -> step5 -> finish
Ideally needs support for "Back" button to return between steps
The problem we have is that any single step in flow doesn't know where it should redirect next and since Play session is very simple, it won't help here much.
Here is the solution we currently have:
Store Flow steps in database in user object with #OneToMany public List<FlowStep> flowSteps
Provide methods in user model to add/remove/skip and change order of flow steps stored for this user
Implement steps normally, with form action leading to "doStep3" controller etc
Implement "Flows" controller that uses #Before and #After interceptors to correctly redirect to next step after current step is processed and no validation errors found
Added Flows.next() controller that redirects to next step (used for "Skip" button href)
What are the disadvantages of this solution? Is there any better way (maybe some Play built-in methods) to improve it?

What you want is a finite state machine. To implement it, you'll need a class that knows all the possible transitions between steps. Then you can provide to it the current step and any relevant input, and it will return the output (where the output is the view to render next).
Then you use render to redirect the user, as in:
render("my/view/path.html", myparams);
This is not the only option, and storage of the transitions will depend on how complex you need them (can be hardcoded for simple scenarios, maybe stored in database for more complex ones), but it should work.
As Play is stateless you'll need to keep the information in the database (for complex scenarios where you need to take in account information for several steps) or, if the relevant togles are just a few, store them in the cookie itself.
I would avoid using #Before/#After as you are coupling the state machine to the controller. Ideally you want them to be idnependent, with the state machine returning only transitions that you can translate later into view paths. That will simplify changing transitions.
If the scenario is not extremely complex, I would not even bother to store them in the database. If you want it reusable and extremely flexible, then do it, otherwise it may be simpler to just "hardcode it".

Did you check this section in the Play documentation (a very quick read):
http://www.playframework.org/documentation/1.2.4/model#stateless
It lists the options you have for exactly what you are asking.

You can try to use Play Cache mechanism as pseudo session to store the validated steps instead of handling in the database. Using Play Cache would be a simpler solution

Pausing and notifying particular threads in a Java Webservice

I'm writing a Java webservice with CXF. I have the following problem: A client calls a method from the webservice. The webservice has to do two things in parallel and starts two threads. One of the threads needs some additional information from the client. It is not possible to add this information when calling the webservice method, because it is dependent from the calculation done in the webservice. I cannot redesign the webservice becuase it is part of a course assignement and the assignements states that I have to do it this way. I want to pause the thread and notify it when the client delivers the additional information. Unfortunately it is not possible in Java to notify a particular thread. I can't find any other way to solve my problem.
Has anybody a suggestion?

I've edited my answer after thinking about this some more.
You have a fairly complex architecture and if your client requires information from the server in order to complete the request then I think you need to publish one or more 'helper' methods.
For example, you could publish (without all the Web Service annotation):
MyData validateMyData(MyData data);
boolean processMyData(MyData data);
The client would then call validateMyData() as many times as it liked, until it knew it had complete information. The server can modify (through calculation, database look-up, or whatever) the variables in MyData in order to help complete the information and pass it back to the client (for updating the UI, if there is one).
Once the information is complete the client can then call processMyData() to process the complete request.
This has the advantage that the server methods can be implemented without the need for background threads as they should be able to do their thing using the request-thread supplied by the server environment.
The only caveat to this is if MyData can get very large and you don't want to keep passing it back and forth between client and server. In that case you would need to come up with a smaller class that just contains the changes the server wants to make to MyData and exclude data that doesn't need correcting.

IMO it's pretty odd for a web service request to effectively be incomplete. Why can't the request pass all the information in one go? I would try to redesign your service like that, and make it fail if you don't pass in all the information required to process the request.
EDIT: Okay, if you really have to do this, I wouldn't actually start a new thread when you receive the first request. I would store the information from the first request (whether in a database or just in memory if this is just a dummy one) and then when the second request comes in, launch the thread.

Managing webapp session data/controller flow for multiple tabs

I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).
The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).
Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.
Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D
The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?
What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.
Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.
Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.
Have you encountered this situation? How did you handle it?

This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.
I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:
pass a windowId with each request, and return it back for the next request. The first time - generate it.
for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId

This is exactly what Seam was created to handle. In Seam there's a concept called a Conversation which basically does exactly what you are explaining. Conversations are basically are a way to divide the Session into many pieces that can expire at some timeout. You can look at the source code for org.jboss.seam.core.Manager class to see how it's actually implemented and get inspired ;)

Depending on the complexity of your application, you may want to investigate implementing tabs within your application. This gives you wholesale control over the flow, while still providing users with the functionality they want. I'd argue it's, bugwise, the most robust solution, since you won't have a dependency on the way the browser handles sessions, minimising the number of "known unknowns".
Of course, there'll be potentially a large upfront cost to this, depending on how your application is structured. Without more information about your app, you're the best placed person to decide.

You can also try to wrap your application inside Adobe Air
And then limit your web application to be only accessable from this air. By doing this you dont need to consider the web browser fragmentation and their unique behaviour.