My prof said that dynamic pages get created by the computer, while static pages are created by the user.
Thank you so much!
The difference between static pages and dynamic pages.
a static page has a generic URL suffix, such as .htm, .html, .shtml, and does not contain "?";
Websites using dynamic page skills can perform more functions such as user registration, login, online survey, user management, order management, etc.;
Application and web languages:
Static web pages: HTML, JavaScript, CSS, etc.
Dynamic Web Pages: PHP, CGI, AJAX, ASP, ASP.NET, etc.
Dynamic web pages are used where information changes frequently, such as stock prices, weather information, news and sports news.
Static web pages have fixed content, while dynamic web pages can have changing content.
Static web pages must be modified manually, while changes to a dynamic page can be loaded through an application whose resources are stored in a database.
Static web pages only use a web server, while dynamic web pages use a web server, an application server, and a database.
Regarding: "How to tell if a website is static or dynamic?"
Static websites are simple web pages (typically written in languages like JavaScript, HTML, CSS, etc.) and stored in a web server. In the case of static web pages, as soon as a server receives a request for a page, it immediately sends a response to the client with no additional processing. Users will always view the same content regardless of their location, device type, and web browser.
In static websites, the displayed content remains the same unless someone manually edits the HTML source code on every page that’s part of the website. These pages contain no alterations based on any user input. Hence the name- static web pages. You don't necessarily need any prior experience with database design and web programming to create and maintain a static website. As long as they don't change when we update them, the code for static web pages stays the same.
On the other hand, Dynamic web pages have greater complexity than static ones because they display different content for each user while retaining the same layout and design. A dynamic website generates web pages in real-time. The flexible nature of the content allows for customization based on the requests from the user or the browser used by them. Such pages are usually written in languages like CGI, AJAX, ASP or ASP.NET, and they usually take more time to load than static web pages. They are frequently implemented to show information that changes frequently, e.g., weather updates, stock prices, etc.
Server-side code used to construct a dynamic web page can generate real-time HTML pages for each request from an individual user. While static websites are mostly informational, dynamic websites contain interactive, continually changing elements. In order to provide an interactive website experience for visitors, web developers usually combine both client-side and server-side programming techniques.
Dynamic web pages usually contain application programs for various services and require server-side resources like databases. A dynamic website accesses content from a CMS (Content Management System), which means that the website reflects any changes made in the database content. These sites use client-side scripting, server-side scripting, or both for generating content. Separating the site’s design from its content makes it easier for web designers to create pages without having to worry about formatting issues. After uploading content into the database, websites retrieve their content from there when responding to user requests.
Now, regarding "Would www.tagpro.gg (the homepage) be static or dynamic?"
I have visited the homepage and it is a dynamic webpage actually as you mentioned.
My prof said that dynamic pages get created by the computer, while static pages are created by the user.
Well, actually also static pages can be generated by the computer, since there are a lot of static sites generators out there. Take for example https://astro.build or https://gohugo.io
Would www.tagpro.gg be static or dynamic?
You are right, it is dynamic, since you can see a login/sign-up feature on the page. That's nothing you can achieve with a 100% static site.
Its very simple... Only major two factors matter -
A static website does not have artificial intelligence means it cannot add something automatically the user has to type the code for that is he wants to do so but a dynamic website can do it on its own.
A static website cannot store a information means it only includes frontend no backend no php, node.js or something like that. In simpler words if user signin to your website you would not able to store his username and password.
Related
I have built my first website. But there are lots of problems, for example when I click poster of article, the data of the clicked poster are loaded to local storage and the opening html page takes these data from local storage and shows. But in that case the unique URL is not generated. every article page has ending article.html. They just loads different data when I click it's poster. I thought maybe there is a way to create new unique html page in your hosting file management system, with Javascript.
There is no way for client-side JavaScript, on its own, to create files on a website.
If this was possible then every major website would find all its content overwritten with whatever random passers by felt like storing.
JavaScript can make HTTP requests to a server (e.g. with the fetch API). You can then process the content of the request with server-side code (written in any programming language you like and that your hosting service supports).
Preface:
We have written some software that allows our users to embed the content of many of their webpage building tools directly into their websites. For instance, our clients use a medley of Landing Page or "Funnel" building tools. Many of these tools are pretty antiquated and don't have a native way to bring that content elsewhere, and our clients don't like to send users to our-client.some-landing-page-builder.com/landing-page.
We have developed some software that will fetch the content at our-client.some-landing-page-builder.com/landing-page, do some work on the action, src, etc. attributes (some of these tools use relative URLs and wouldn't change them to absolute for us), and then it gets embedded directly into their website, our-client.com/landing-page/. It uses an optional cache or microcache to make sure that the content is fresh, and it has been working excellently for years.
The Problem:
When a user visits our-client.com/landing-page/, and the software makes a request to the content on the Landing Page builders, the request that is sent belong to the our-client.com and not the user that visited the site. For most of our clients, this isn't an issue.
The Question:
We have one client in particular that is asking if there's a way to send that user's request headers from our-client.com to some-landing-page-builder.com?
I was going through page source of famous websites like twitter, instagram, snapchat etc. One thing I found common in all these websites is that there are no input tags in the page source of login/signup page. Infact there is no form tag at all. I wonder if its a security measure or something else. Can anyone answer me this?
It is a side-effect of an overreliance of client-side programming without server-side rendering as a fallback.
It has nothing to do with security whatsoever.
In the early days of the web, all was present in the HTML code. There was little dynamic on those pages.
Through history the pages became more and more dynamic, with more JavaScript. Some document elements were created through JavaScript, in response to some user events (like adding rows to a table). This became a pattern that extended also to the initial build up of the page: some popular libraries are completely built around that idea. In the extreme, the HTML only contains one script tag (besides the html and body elements), and the JavaScript does the whole job of generating the page, based on some other configuration (in a database, configuration files, JSON, ...). It takes away the HTML design, and moves this responsibility to JavaScript.
This is not a security concern. Just one of the ways some frameworks work.
The browser's page source only displays what is rendered on the server. We call this Server Side Rendering.
These days, with the concept of Client Side Rendering, most of the webpage is generated on the client side, with JavaScript frameworks like React.js. The server just generates the basic skeleton HTML.
So, to answer your question: Why are there no input tags in the page source of login/signup page - This is because these input tags are generated at the client-side using Javascript. This does not mitigate any security risks, as the input tags are still accessible via the DOM inspector
It's not bad, it's just not the way those sites work. They likely use a javascript front end app and POST data to a back end API of some sort to do the login.
Input tags hark from an older variation of the web where the server prepared a page, sent it to the browser, the browser user filled in form fields, sent the data to the server as an encoded form, the server prepared a new block of html and sent ti to the browser. You'd see the page refresh with different content and huge amounts of html was flying round all the time. Some tricks were employed by browsers to make it look like a more seamless experience but there is stil lthe underlying method of working, that the whole page was replaced
The modern web tends towards single page applications; a page loads with a javascript application and the script manipulates the browser document to draw the UI, there is never again a situation where the server is wholesale shipping entire pages to the browser for display. It's all "script sends some data, probably json, to the server, gets a response and programmatically updates the local document making the browser change what it displays"
To this end somewhat the browser has become an operating system or development environment, with programming features, and access to local resources like webcams and file, and it forms a front end UI with the back end server holding and processing the data that makes the application valuable (worth purchasing or using). It's not about security, but instead about making a modern, dynamic and usable UI for a web-based application. There's no reason why they could't use an input tag; the javascript app running in the browser could create an input box, the user could type into it, the javascript app could pull the value out of it and send it to the server (not in a form) and get the response.. It's just that they don't need to work that way; there's a lot more freedom to get user input in various ways, send it to the server in various ways and act on the response. We are no longer tied to that older "post a form to the server" way of having dynamic content, and we haven't been tied for a long time but it's relatively more recently that really good frameworks and libraries for creating these single page apps have come along, so increasingly we see sites using them for the benefits they provide and they might bring with them ways of garnering user input without using an input tag - ways that are not subject to some limitation (probably styling) that using the tag incurs.
The modern web is mainly centred on end user experience with a more rich and fluid ui, less data being transferred for faster response times etc. All this chat between front end and back end (should) happens over HTTPS in the modern web (the CPU cost of encrypting being relatively low in these days of high powered servers and clients) so it's at least as secure as it ever was.
TLDR; input tags are less often used because they're less often needed and may bring some problems and blockers to the modern ways of developing. They aren't inherently insecure.
I am wanting to serve various users a index.html page however certain users can only see certain elements such as buttons for example. I'm using the Express framework, I know you can "register" views then feed the allow / deny certain web pages to a user but I want to allow / deny certain elements for a webpage when the login. Was wondering if anyone has experience in this?
This is a relatively common use case. Logged in users generally show some sort of account link, while logged out users generally show a login button, or perhaps a signup button.
I have never used express, but its documentation suggests using jade templating engine which should support conditionals.
http://expressjs.com/guide/using-template-engines.html
With jade, you could render an index.html using a context containing a user, and render the specific template elements conditionally:
http://jade-lang.com/reference/conditionals/
Another approach is rendering completely separate index.html files based on your user classes.
tempalte inheritance is another powerful tool to render similar templates to different users. Generally it is used to contain your base template information, ie site-wide header, footer, body container
and keep in mind, conditionally showing links and elements and buttons on a page isn't enough to protect your site, if a user shouldn't access a specific endpoint then authentication/authorization needs to be enforced on the server side
I want to create a page that "silently" queries other pages. It then crawls them for a result. When it's done querying all the pages, then it should calculate its own result according to the results retrieved.
What I meant with silent is,
the other web site's code shall not appear on my page, nor affect it in any way
I want each other page to be queried in a different session (like when I open a new tab for each in my browser) or something similar. So that there will be no namespace problems.
I heard chrome would offer something that might be helpful for that?
edit This is NOT about crawling web pages. It is for fetching data from other local stand-alone projects
edit2 I am just looking for an alternative to simply looping URLs and querieng them, because there are namespace issues
You can't access pages from other domains with JavaScript unless the domain explicitly allows your domain.
Typically you would use a server-side language for this, or better, use the website's public API. If they don't have a public API they probably wont appreciate you crawling their site.