Hello community. After several months of work, it's time for me to present my most ambitious open-source project. It's not finalized yet; there are still bugs and features that need to be added, but it's stable enough for you to "play" with and give your feedback.
### What is Phoenix?
Phoenix is a modern template engine for Spring and Spring Boot aiming to facilitate the development of complex web applications by providing a way to create complex and modular templates benefiting from server-side rendering for better integration between the frontend and backend.
### Phoenix vs Thymeleaf or Freemarker
Phoenix offers several advantages compared to other existing template engines at the moment:
- The ability to integrate Java code directly into HTML templates without needing to learn a new syntax or special utilities.
- An easier-to-understand syntax that only requires a special character "@" to integrate Java code into HTML code.
- Fragments or components that can be combined and reused, making the code easier to maintain.
- Speed, speed, speed - Phoenix templates are compiled, offering rendering speeds up to 10x faster compared to Thymeleaf.
- A single PhoenixController that easily allows the return of both HTML pages and JSON responses.
- Reverse routing - a completely new feature for Spring. URLs are written at runtime in templates, eliminating the need for manual writing. You only mention the controller and method, and Phoenix calculates the correct URL. This way, you can change the URL in the controller without having to modify the template.
- Pages dynamically modified by calling from JS to the backend to obtain a ready-to-add fragment/module to the DOM.
- Easy to configure* (Work in Progress to reduce necessary dependencies).
### Why Phoenix and not React/Angular/Vue?
Phoenix is not intended to be a replacement for JS frameworks. Instead, Phoenix aims to utilize existing JS frameworks to add SSR, thereby enhancing page rendering speed and FE-BE integration. You no longer need to always return complex JSON; you can directly provide an HTML page with everything needed and nothing more. There can be a whole debate about SSR vs non-SSR, so Phoenix tries to combine the advantages of both.
###Open Source
Phoenix is open source, and everyone is encouraged to download the code, contribute improvements, or suggest features.
It has been made many times, but I could not find something that works easily out of the box. After I made it, decided to share it since others may find it useful.
Here is some information about this pattern, it's called Immediately Invoked Function Expression. It's a way to create a function scope so that all variables are local, except for any that you want to "export" as a global.
The past few days I've been working on a personal project and needed to add file-upload functionality to an existing form. So, I was searching for something to make things elegant and allow also drag&drop, not just the traditional file browser.
I could not find anything that fit my needs (DropzoneJS required too much workaround to work with my existing form), so I decided to make my own from scratch. It turned out quite well so I decided to make it open-source, since I think other may find it useful.
- It is theamable, and only requires update to the css file
- Does not require any external libraries like JQuery (it is made with pure JS and CSS)
- Small and lightweight, currently having less than 4kb for both the JS and CSS files
- Shows you the thumbnail preview for images (configurable)
- Easy to configure (even though there are only a few configuration options)
Any suggestions of improvements (or even better, code submissions) are greatly appreciated. Please, tell me what you think and if you think that this is useful and I should continue development.
Looking good and great job! I noticed an errant apostrophe in the README: While the library is in it's early stages should read While the library is in its early stages Thanks for giving the world this!
Author here! I know that the title is a bit click-batei, but did not know how to better say it clearly. In the article I show two real-life examples of input-validation failures and why it is important to have server-side validation for the data received from the user. Also, I don't recommend using this for your channel (or any such service), due to the really bad quality of the subscribers.
Hi all! This is my first open-source project and I hope I managed to create something useful. LogMasker is a library that helps with masking confidential data inside logs. It is easy to integrate in both Log4j2 and Logback, configurable and can mask IPs, emails, passwords, IBANs and Card Numbers. The library is still in it's early stages, with hopefully more features on the way. Any feedback is highly appreciated.
First, I must add that it is not my article. Just found it interesting.
Related to the language, it sais it is OpenCV. I don't know if javascript has access to the actual image data from the webcam, but if it does, it may work.
WOW! This was a really interesting read. I don't even know exactly where to start. I never looked into G+ (and was nowhere near as good as a programmer as I am now), but those were really cool findings.
Related to UUIDs, it does indeed protect privacy and protects the server from crapping and leaks. It is not enough for security, but it does make it harder. Internally you can still use sequential IDs for the PK so that speed is not impacted.
Both of you are assuming random IDs protect user privacy. The only thing I can come up with where that to be true (without things that no one was ever seriously suggesting or using, such as a sequential identifier that increments on something per user) is that someone who is unable to see a resource otherwise will know when it was created (and in fact the time when something was created is now information about a thing "at all" when it otherwise might not have been). What am I missing?
Otherwise, the arguments against sequential identifiers seem to mostly come down to either people who somehow dislike scraping (which I might even argue is immoral, and I think this great comment from dredmorbiu come at it from the correct mentality; hell, I strongly prefer it--as a potential user--when a site is scrapable) or people who don't want anyone to know "true truths" about their service, with examples such as "our user growth figures" (but these help the site operator, not the users).
(I am also surprised to see Parlor brought up even in this great comment about "you didn't really stop me from figuring out what I wanted to know": to the extent to which you want to do "defense in depth"--which I honestly find frustrating as an argument by itself, as you can use that to justify almost anything, including absolutely ridiculous things we tend to claim are "security by obscurity"--you are going to then need to make sure you really really lean into the idea that "we wanted our site to not be scrapable, even to an administrator", which I can't imagine anyone ever actually doing for myriad reasons including how sites usually help search engines.)
- Not all systems make user data (or all user data) visible. UUIDs make guessing or traversing the address space harder.
- Certain types of attacks are easier given known, guessable, predictable, or sequential identifiers. UUIDs mitigate these attacks.
- Certain types of system confidentiality are generally easier to maintain with UUIDs. (Unless, of course, you then hand over the full listing, as Google did with G+.)
- Where merging systems, UUIDs may (or may not) help avoid namespace collisions. (Merging disparate systems with independent UID conventions is a notoriously fraught problem.)
On sites helping search engines: so far as I've been able to suss out, Facebook actually leans strongly the other way. I don't seem to get much insight to Facebook by trying to do site:facebook.com limited searches (through DDG, which is to say, Bing, or Google). FB's view seems to be that if you want to see or search content on the site, you create an account and go there through the account to find content. I don't often find myself interested in searching FB myself, but for as large a site as it is, it seems to turn up in results remarkably less often than other notably closed/annoying domains, say, Scribd or Pinterest.
Even as of 2015, FB's representation among various traditional and social-media options for a set of arbitrary interest queries was relatively modest (though higher than I'd recalled before going back to look at my results) and I believe (based on impressions rather than focused research) it's become more search-engine opaque since:
Possessing an ID, shouldn’t give access, regardless of whether it’s a numerical PK or a UUID. (Unless that’s a feature, like shareable links) Still need to check if the user should be able to use that ID.
If that isn’t implemented, the system isn’t secure, doesn’t matter which path you use.
If the ID scheme mapping is sufficiently dense, traversal attacks on otherwise obscured namespaces become an option.
This might apply to user accounts, posts, payment accounts, or other elements.
Security isn't simply about compromising account credentials or access policies. It may be any unintended or unexpected data disclosure, inferred relationships (between accounts, activity, finances, offline attributes, access, reputation, and more), denial of access, stalking or harassment, and more.
These might not be unexpected in all cases, but could well be undesired in many instances.
Using UUIDs externally is not only for privacy, but for security as well. There are attacks that are easier if you can guess the IDs that are being used. Also, not all systems are meant to be scrapped or deal with user-generated content.
I remember a few years back a data leak of stored financial information because the IDs provided for them in the "My Cards" section used sequential IDs. A simple script could scrape credit card data. Yes, I know that there were other security problems as well (not checking if a user has access to that card, storing it in a non-PCI compliant way, etc.), but still, the fact that the internal sequentially-generated PK was provided to the outside world, made things a lot easier.
Right. I'm referring here to the external affordances of UUIDs. Site performance is not my concern ;-)
The degree of programming involved in all of these exploits was laughably small. The Ello link literally includes the script I'd run for the G+ data pull, it's a bash one-liner. Parsing mostly consisted of a regex grabbing and isolating the posting date and follower counts from the rendered HTML.
The larger point being that if you provide a reference to the UUID set, sampling becomes easy, is ... well, come to think, if you're assigning sequential IDs and I know the upper and lower bounds of that range, I can still sample randomly from within it.
The problem of exhaustively searching a large-relative-to-references UUID space also apply, though I'm not sure if/how that might impact internal or site operations.
There are many data leaks that result from exposing the internal IDs of your data. These are easy to guess if you use sequential/auto-incremented values for the primary key of your data and later share it outside. here is how I think you can avoid it without sacrificing performance.
Using the power of Streams in Java 8 and with the help of Lambda Expressions we can do easy, fast and reliable manipulations on Collections. We can easily filter or sort lists as well as other operations, regardless of the overall complexity.
### What is Phoenix?
Phoenix is a modern template engine for Spring and Spring Boot aiming to facilitate the development of complex web applications by providing a way to create complex and modular templates benefiting from server-side rendering for better integration between the frontend and backend.
### Phoenix vs Thymeleaf or Freemarker
Phoenix offers several advantages compared to other existing template engines at the moment:
- The ability to integrate Java code directly into HTML templates without needing to learn a new syntax or special utilities.
- An easier-to-understand syntax that only requires a special character "@" to integrate Java code into HTML code.
- Fragments or components that can be combined and reused, making the code easier to maintain.
- Speed, speed, speed - Phoenix templates are compiled, offering rendering speeds up to 10x faster compared to Thymeleaf.
- A single PhoenixController that easily allows the return of both HTML pages and JSON responses.
- Reverse routing - a completely new feature for Spring. URLs are written at runtime in templates, eliminating the need for manual writing. You only mention the controller and method, and Phoenix calculates the correct URL. This way, you can change the URL in the controller without having to modify the template.
- Pages dynamically modified by calling from JS to the backend to obtain a ready-to-add fragment/module to the DOM.
- Easy to configure* (Work in Progress to reduce necessary dependencies).
### Why Phoenix and not React/Angular/Vue?
Phoenix is not intended to be a replacement for JS frameworks. Instead, Phoenix aims to utilize existing JS frameworks to add SSR, thereby enhancing page rendering speed and FE-BE integration. You no longer need to always return complex JSON; you can directly provide an HTML page with everything needed and nothing more. There can be a whole debate about SSR vs non-SSR, so Phoenix tries to combine the advantages of both.
###Open Source
Phoenix is open source, and everyone is encouraged to download the code, contribute improvements, or suggest features.
Source code: https://gitlab.com/ppopescu/phoenix-template-engine
Wiki: https://gitlab.com/ppopescu/phoenix-template-engine/-/wikis/...
Build jar: https://gitlab.com/ppopescu/phoenix-template-engine/-/jobs/5...
My blog: https://petrepopescu.tech