Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: SDN Journal, Java IoT, Microservices Expo, Containers Expo Blog, Machine Learning , Agile Computing, @CloudExpo

SDN Journal: Blog Feed Post

Social Loginwall Failure

It is not uncommon today to click an interesting link you see on Facebook only to be confronted by a "social loginwall"

It is not uncommon today to click an interesting link you see on Facebook only to be confronted by a "social loginwall". If you aren't familiar with that term it's probably because I just made it up to describe the use of CSS overlays to "hide" the content you want with a second overlay, usually containing a plaintive "login or register to see this content" dialog.

It's annoying, particularly if it's a random site you're not sure you want to visit again and aren't comfortable openly sharing the gory details of your Facebook life with some third-party site.

So what do you do? Close the tab? Swear? Sigh and move on?

Not me because, well, I can read a DOM and I'm a developer by trade and Chrome has generously made sure I have access to a debugger that can modify in real-time just about any piece of a page.

That "delete node" option neatly eliminates the "social loginwall" with only minimal irritation on my part. Couple clicks and voila! I'm reading what you thought you were gating.

The lesson here is if your business model (and logic) require that a visitor be logged in to see certain content, you'd better make sure that it's enforced somewhere other than on the client.

C'mon. I've got marketing in my title for crying out loud. If I can circumvent your attempts to enforce application logic flows then, well, lots of other people can and honestly, there's probably a plug-in that will do it automatically for folks who aren't trained as developers.

DOMAIN (APPLICATION) LOGIC
It seems increasingly there's a disconnect as application architecture transitions from its traditional client-server model to a modern, API-based model. That disconnect is caused by the reality that the API is focused on data and business logic - not domain (or what we might call application logic). So that logic that controls state, that controls access to data, ends up where it doesn't belong: on the client, in the presentation layer.

And because the technologies used on the client, in the presentation layer, are almost exclusively* markup language that must be parsed and rendered, well... it's fairly easy to circumvent client-side application logic as well as the oft-times rudimentary security mechanisms. Evidence of that is seen in the OWASP Top Ten, where XSS and CSRF remain two of the top vulnerabilities developers (and devops) should be addressing.

And yet the exigencies of the mobile explosion complexify (yes, I made that one up, too) addressing such issues. On the one hand, we could go back to a more traditional three-tier architecture, but that reduces the benefits of the emerging, API-centric model in which the server-side components are focused on data, while the client worries about presentation (GUI). On the other hand is a new, emerging model that more concretely implements the application best-practices model.

There's That Strategic Point of Control Again
That's the CLIENT INTEREMDIARY SERVER pattern, and it's important; it provides a light-weight, intermediate tier on which to provide security and application (domain) logic enforcement without disrupting the basic model. The proxy, like the application delivery controller model, provides a strategic point of control at which a variety of client and server-side operational risks can be addressed. This point of control is also the appropriate place to provide metering governance. The technical point of metering is, after all, to reduce the load on services to ensure availability. If the service has to make the determination whether a request puts a user/application/partner over quota, it defeats the purpose because the resources are being consumed anyway.

Metering through an intermediary, however, insulates the service and provides a better assurance of availability. It also enables a programmatic point in the data path** where new authentication and authorization can be provided, without modifying the service itself. Most important, however, is the elimination of as much application (domain) logic from the client as possible to avoid the consequences of exploitation of both application and security-related logic.

*Plug-ins, while theoretically safer, are not without their own risks. See "Adobe Sandbox: When the Broker is Broken"  for a good example of this.

**Starting to sound like Application Layer SDN? It should...

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
Machine learning provides predictive models which a business can apply in countless ways to better understand its customers and operations. Since machine learning was first developed with flat, tabular data in mind, it is still not widely understood: when does it make sense to use graph databases and machine learning in combination? This talk tackles the question from two ends: classifying predictive analytics methods and assessing graph database attributes. It also examines the ongoing lifecycle for machine learning in production. From this analysis it builds a framework for seeing where machine learning on a graph can be advantageous.'
Daniel Jones is CTO of EngineerBetter, helping enterprises deliver value faster. Previously he was an IT consultant, indie video games developer, head of web development in the finance sector, and an award-winning martial artist. Continuous Delivery makes it possible to exploit findings of cognitive psychology and neuroscience to increase the productivity and happiness of our teams.