I have an internal .NET 4.0 web forms app with a sql server backend. I have a menu on the home screen that I need to show/hide parts of based on which groups the user is in. I am struggling with the best way to do this. In the past I have called js functions from the code behind using ScriptManager.RegisterStartupScript. However, I feel like this is bad practice and don't want to keep doing it if it is. I know I could just set my html table cells that need manipulating to runat server and add the property in the code behind when I lookup the user's security. Should I do that and forget about trying to go back and forth between the code behind and js? Or, is there a way to accomplish this that is good web programming practice?
Seems like this is a common scenario, which is why I think I'm missing something obvious. Lookup something from database, then execute js to manipulate front end.
Note: I bounce between plain js and jQuery, so feel free to answer with either.
Related
Hi I'm new to dynamic web dev. I've searched this site but couldn't find anything similar.
I want to implement a password checker, for robustness and length etc. Fairly conventional. The thing is, I have 2 options: 1. embed javascript inside an HTML. 2. embed javascript inside a jsp file.
With a little preliminary research it seems that most people recommend the former, that is to go with HTML. I wanna know why? I could be completely wrong, in that case I also wanna know why?
The "how" isn't all that important, but "why".
Edit: I know this question is full of flaws (for example JSP and HTML aren't mutually exclusive) but please indulge me a little bit and tell me which scheme is more appropriate, if I want to get things done front end, in a user's browser.
Edit#2 : Sorry I did not provide any bg information: I am working on a larger project and password checker is just a part of it, the project itself is a dynamic web project relies predominantly on java, serverlet.
As you state you are new to dynamic web dev. JSP is a server side programming language Just like PHP and others. If you want to confirm password, you can use ajax to check for a match from your database and if match was found create a session and redirect your user to the logged in page. If i misunderstood your question, please try to be clear enough.
Depends on your use-case. In some cases, just the front-end is enough. In many, I would say both is better.
By putting it in the front-end/client-side (the "HTML"), you create a more user-friendly approach, since you can rapidly and continuously evaluate the users' input and give them feedback.
If the application doesn't need to be particularly robust from a security perspective, this can be plenty.
The downside of HTML only validation of any user input is that it can easily be bypassed. As a programmer, I could figure out what its doing and easily bypass any and all client-side protects. Users can also wholesale just disable JavaScript, so if your site works without JavaScript in general, they won't get any validation. This is why "security" on the client side is never a thing. Never trust the client.
Implementing it only on the back-end/server-side ("JSP"), you can lock down the security since the end-user can't bypass any of your validation. It must match the rules you set forth.
The downside to server-side is that you must send the data to the server to be analyzed, then wait for a response. While this may be fast, its still much slower than client-side.
By doing it in both, you get the best of both worlds. You get the rapid feedback for the end-user without having to send any data to the server, and you get the full protections of making sure it is properly validated on the server-side.
The downside to this of course is you have to double-up on your code, so its more effort. That's why you want to weight the pros and cons in your particular case, as there isn't a single "best" answer.
If the HTML is enough for you - why should you use .jsp?
You need .jsp for creating dynamic content and it's gonna be compiled as Servlet - do you actually need Servlet in this case?
If security is not a big concern then HTML + javascript should be fine. It will be responsive amd lead to better user experience.
If this is an external facing application on the web then as mentioned in some of the other answers go with Jsp approach.
I've mostly worked with Springboot framework only with JSP to cover the things I need for the website part. Now, I've got a project to do that mostly revolves, if not all, around the website and I have a couple of questions.
Just to be clear first, I don't have experience either with Thymeleaf or Angular so whichever I pick will be the first time (I think thymeleaf syntax would be easier for me to handle).
Ok so the main goal in my mind is not to render the whole page every time I load data from the backend, so I figure I would have like a header/content/footer parts where every time I click something only the content part would change. Also, I would like the possibility for a loader to show and go away when the content part is changing. This web application will need to be secure for users that register.
I've searched the web to investigate both frameworks, but can not seem to find the right answer so I can continue with my development
I do not mind creating separate REST services in later development if some other platform needs to hook up to the service if I decide to go with Thymeleaf.What do you guys think in what direction should I go, Thymeleaf or Angular? Any help and/or discussion would be much appreciated.
I am sorry if this seems like a general question, but I just need some basic guidelines to start with. Cheers!
I think transitioning to ThymeLeaf is probably going to be the easiest for you, but Angular is a great choice as well, and from there it is up to you. Would you rather use mostly expressions similar to JSTL expressions, but in Spring's SpEL language, then use ThymeLeaf, or would you rather use JavaScript, then use Angular. It just a user's preference for what you are doing.
The fragmenting portion (header, footer, body, etc..) is native to both frameworks. It just depends on which one you want to use. Whatever you go with, to load specific sections while not rendering the others, is going to require AJAX and for you to feel comfortable with how the template frameworks work.
I would suggest reading up on both of them to figure out which one you feel more comfortable with.
Angular
Thymeleaf
Both of them have great documentation for beginners and the Baeldung and Mkyong have good walkthrus for ThymeLeaf. Angular's documentation I found good enough on its own.
For a loader, you can do with simple CSS and JS. There is a ton of demos out there on how to do full screen loaders and how to turn them on or off with JS or CSS. IHateTomatoes has a good article about how to build a full screen loader, that has a No JS fallback option and should give you a good starting point.
Your point about it needing to be secure is a whole other monster. I would look into Spring Security. It's relatively straightforward, especially when using Spring Boot. If you want it can control the users session and assist in preventing session jacking, add CSRF to prevent cross site forgery, control permissions to urls and on down the line, or not. It all just depends.
Either way, don't randomly stab at security, it will end up in something that you feel is secure but it is not, which leaves you and your users in a very bad spot. Again, Baeldung has a great walkthru on the user registration and login process that can help get you started with Spring security and how to tie everything together.
Pretty high level answer, but hopefully gave you some good starting points and some resources.
Build apps decoupling frontend from the backend.
Always build apps following the "The API-first approach"
The API-first approach involves setting up the foundation of your app, which is the application programming interface
For me the differences between Thymeleaf and Angular:
Using Thymeleaf: You don't need to create Restful/web service endpoints on your frontend side because you just need to make calls to the backend from the frontend itself.
Using Angular: Besides of your Restful/ web service endpoints on your backend side, you have to build Restful/ web services endpoints on your frontend side because you don't want to expose direct access from Javascript code to the backend.
Hope this helps and happy coding time!
I'm just now tapping into real GUI-heavy stuff and I'm looking to integrate a GUI for a Python 3 application/("game"?). I need this to be cross-platform, responsive, and able to communicate with other users and a server.
I've looked at desktop application creation but I think that the best thing would be a web application. Now, here are the obstacles:
I need the web app to be able to use all my Python 3 code as its black box; it needs to be able to send a function call to the running python code.
More often than not, everything on the page is changed if a single value is changed.
If another user changes a value, it would affect multiple other users instantaneously.
I can't have the page constantly refresh.
The HTML "GUI" needs to have some degree of separation from the Python code. (I can't have Python sending snippets of HTML, only data is allowed.)
I realize that this is a lot to address, so my question then is:
How would one go about making a web app that has specific (most) data values update consistently without having to refresh the entire page?
My proposed solution would have some sort of simplistic javascript constantly checking to see if anything has been posted for the users closely interacting with each other (players in the same server, if you will). Each value in the HTML would have a linked javascript function which is linked to a value or function in the backend python code.
"Player" changes value on webpage -> JavaScript function call -> Python black box on "Server" -> JavaScript checking loop sees that there has been a change via simple Python variable on "Server" -> JavaScript gets all values via calls to functions in python code -> Update HTML for all "Players"
Finally, please note, I have no idea how to carry out my proposed solution, and I very much welcome a different, better approach. Thanks in advance.
So, for anyone who is trying to do the same thing as me, the answer is something called "websockets".
I initially tried Kivy, but found that it was too cumbersome and just hard to get good styling in. Using HTML, CSS, and JavaScript, you can make pretty fancy looking stuff, and Kivy just isn't robust enough to make something attractive without having to write tons of excess code. Since what I'm trying to make is basically a styled data readout/hud, the HTML combination takes the cake.
What I'm currently using for the websockets is a module called "Tornado" which allows you to update any data on the client side without them reloading the page. I'm sending this data as a single JSON to update the whole page.
In conclusion, I decided on HTML/CSS/JavaScript for the GUI and Python/Tornado for fast server-side computation.
First of all, I'm not much of a programmer if at all. This question may seem silly but I would honestly like some advice from real programmers.
I'd like to make a bit of an adventure game on a webpage.
Could I make it by having a MySQL database setup to store variables while JavaScript, HTML and CSS is used for the user interface and JavaScript for the game programming and PHP to communicate with MySQL.
I don't entirely understand it but I followed a tutorial and got it working. It also showed me how you can replace text on the screen by giving that text an elementid and then just setting its value to other text.
In this tutorial script, it has it so when the JavaScript file wants to communicate with php, it will open the php file with a ?=value at the end of the hyperlink where the value part turns into some kind of MySQL search value.
Something like this:
xmlhttp.onreadystatechange=function()
xmlhttp.open("GET","index.php?q="+str,true);
and then in the PHP file:
$q=$_GET["q"];
$sql="SELECT * FROM user WHERE id = '".$q."'";
This means you will always search by specific id number. The problem with this is that the php file is always set to look at the exact same table.
Sometimes you want to look at different tables, or multiple values from multiple tables, etc. Basically, you should be able to select each value like it's a record from one of those automatic DJs that radio stations used to have. Also, sometimes you'd want to write or append the database like when variables change and need to be updated and all of that has to happen securely.
The only thing I can think of is to have a ton of php files that work the same way and call the appropriate file when you want a certain kind of response. But then if I have a file on my website that has a php file that lets me write TO the database then someone can just read the javascript code, see that, and then basically hijack the mysql database.
So how can I securely do this?
I would recommend you to look into using jQuery and Ruby on Rails.
jQuery is a JavaScript library that will make easy your interaction with a server (MySQL) and will help you to get code that works in a lot of different web browsers.
Ruby on Rails is a web framework that will encapsulate everything you need to store state (game data) to a database (MySQL) and handle secure communication, as well as a host of other needs you may eventually face.
In addition to jQuery and Ruby on Rails, there are tons of other comparable frameworks you could use.
YUI3 (http://yuilibrary.com) and Django are two more examples. Express (for Node.js) is a JavaScript back end framework (like Ruby on Rails) that you could use with your existing JavaScript knowledge.
Anyway, good luck!
Theoretically, without moving towards different frameworks, here are a few things to think about...
I think you have the right idea with this what you are trying to do. The PHP file is used as server side logic. It should not be available to the user.
What the user can see is that there is a function available to make changes to something. This he will see from your AJAX call in JavaScript ( xmlhttp.onreadystatechange=function() xmlhttp.open("GET","index.php?q="+str,true); ).
Your responsibility, in the PHP (server side logic) is to make sure you scan the parameters to this function before you allow any changes to be made on the Database.
As with any requests to a database, you need to make sure you are escaping the parameters before any call is made to prevent SQL Injections.
As with previous answer, there are some libraries that exist that have some tools already built in. Some poeple prefer certain tools/languages/libraries over others, but they can all pretty much all do the same thing. What changes is a bit of how it's done. I think you are on the right path, just need to protect those PHP pages of injections and inputs/parameters you do not want.
If you are using multiple PHP pages for different actions, it is possible to have the same PHP script accessed from all other pages. Therefore your escaping (preventing SQL Injections) can be done in the same script and don't need to include it in every single PHP page that makes a database call.
Hope this helps a bit!
I'm working with a third-party search API, and am rather enjoying keeping pretty much the entire application on the browser side. The XML is digested entirely with javascript, and I'm rendering complex result objects dynamically, using a javascript templating engine. There are few page reloads happening, and lots of fancy javascript going on.
It feels clean to me to keep everything on the javascript side. It's going to make deployment much easier, and it's nice to have all my code in one place. I'm trying to be just as rigorous about coding well with javascript as I would were I coding in Java, and so far things seem to be working pretty well. I'm making an effort to work TDD style, using YUI test, and am optimistic that this will make the inevitable cross-browser bugs easier to catch and fix. The code size is not minuscule, but it's not too bad, and I plan to minify it before deployment, which should reduce it to about 2/3 of what it is now.
Are there drawbacks I'm not considering? Any other proponents of front-siding application logic here?
There are few page reloads happening, and lots of fancy javascript going on.
There is one large drawback to relying too heavily on JavaScript. Remember that whenever you design a web application you should base it on the premise that the user doesn't have JavaScript enabled - although this is a minority there are still a lot of users who don't have it enabled for whatever reason, and if your application relies too heavily on JavaScript in its fundamental operation, then it won't be accessible to those who disable JavaScript.
Whenever I write pages that have JavaScript or AJAX functionality I always make sure to have a secondary way of information being displayed or submitted, in case JavaScript is turned off on the user's browser. Of course this often isn't necessary for aesthetics - menu items sliding along a menu bar when clicked and the page is changed won't affect the core functionality of the page if JavaScript is turned off and they simply act like static links; however for core features such as inputting data and having results displayed, you should ensure to provide backup methods that are employed when JavaScript is not enabled.
You should use AJAX only when it actually improves user experience. It is very annoying when trivial functionality requires JS needlessly. I would expect (no idea if it's the case for your app) to be able to enter a search, get the results, and page through the results all without JS.
There's nothing wrong with "extras" like AJAX paging or search refinement. But the essentials should be there either way.