Hello Hops, Now that Hiromu has been making absolutely stunning progress on merging his Hop Web changes into the main code-line we're seeing hiromuhota/hopweb:nightly behave like a champ.
As a reminder you can give it a shot with: docker run -d -p 8080:8080 hiromuhota/hopweb:nightly That being said, a hop.war file is being generated in the main build now in assemblies/web/target/hop.war You should be able to throw that into a web server webapps folder to get it up-and-running. This does bring the security question around hop-web on the table though. The requirements around this for me are essentially that we should be able to develop data orchestration solutions in a browser with one or more developers on the same server. This means allowing files to be changed by multiple users, multiple git repositories and so on. I predict that things can get problematic if we don't do something about that. *Security & ACLs* I think at some point we might want to implement some kind of mapping between an authenticated user (say [email protected] authenticated via OAuth) and a hop-web user. Now this hop-web user typically has access to all files on a server unless we invent something to restrict that access. We could make it so that the file dialog only allows you to browse to certain folders or more specifically, specific project folders. So the list of mappings could be: AuthenticationUser - HopUser - Project *Action based security* I can also see a use-case, obviously not just for hop-web, for having action-based security with the absolute minimum being some sort of read-only mode. Action based security can be sprinkled throughout the GUI and runtime code as long as we have the metadata to validate actions. We need: - User/Role ACL - The subject (specific file, category, metadata object, ...) - The action - Allowed/Denied - Arguments Example: User(matt) is Allowed to Action(execute) a Subject(pipeline) with Argument(pipeline run configuration="local") Once we have this security metadata "database" somewhere we can just add one-liner checks in the code. For example right before we run a pipeline: HopSecurity.validateAction( pipelineMeta, HopActionType.EXECUTE, ...); This could pick up the current user and validate it. If there is no security layer defined or no user it will just be ignored. *Locking, messages & code review* Finally if you're working with multiple developers on the same project there is a high chance that you'll be tempted to work on the same file at some point. Having the ability to do a soft or hard lock on a pipeline or workflow would be really nice to have (and fairly easy to implement). If you open a file to work on you could see a message from a user saying: "*Sorry, I'm working on this file*". You'll open a read-only version of the file. With a soft lock you should be able to just ignore this and edit anyway. Messages also could be very easy to implement in the form of developer notes on a file or project level (where it matters really). Code-reviews finally are IMO just a variant of that with perhaps an extra status that we keep on a file/project level. (Has remarks, partially approved, approved) If messages, locks and reviews are implemented as metadata objects we could check them into the project itself. They'll become an intricate part of the project itself. We could prevent a push to upstream in git for example until the project review status has reached Approved status. Anyway, just a few ideas to discuss. Have at it. Cheers, Matt -- Neo4j Chief Solutions Architect
