We Keep Coding

Record unique views on the web with Firebase Realtime Database

I'm building a React web app, where users can create 'content'. The content is displayed when a certain URL is visited, e.g.: https://myapp.com/username/contentid
The user doesn't have to be signed in to view the content.
My question is, how do I track unique views with Realtime firebase?
I don't necessarily need a code implementation, rather an idea/approach. Thanks!

First, you would need to enable your database to allow for writing capabilities from anonymous users. From there, write to the database when the site is first opened. You could store this information in a variety of different ways, I would recommend posting a timestamp and seeing total unique views by counting the total amount of timestamps uploaded. It may also be important to store locally, via Cookies, if the user has been to the site already. If they have, don't write.

Best way to keep authenticated user profile in Angular2

I am using Angular2 & Auth0 to Authenticate a user.
Currently, according to their "best-practice" , the user profile is saved to localStorage , and once you need to pull information, take it from there.
This sounds like a bad practice to me, is there a better way to keep logged in profile for local query (name, photo etc.)? maybe using an Angular2 service?

The problem is if you want to keep the user profile for later use (if the user close the window and reopen it later) without having to make request to a server. Then you need to store it somewhere.
And storage facilities in the browser are quite limited: IndexedDB for database storage with query capabilities, indexes, etc, localStorage for simple key=>value storage,or even cookie for a limited amount of data as plain-text.
but if you don't need the data for a later use, you can keep it in memory (in a service, for example).
You can also combine both in-memory and offline-storage in a service.

You can combine both ways.
Storing it in localstorage to get that infos without request them anytime and wrapping a Service around it to not address the storage from everywhere.

how to maintain check boxes state across jsp pages whenever you come back on a page using javascript or jsf without storing it into database

i want my all check boxes checked whenever i come back from other pages, i want to maintain their states across pages using javascript.

I think you are asking how to store state for an individual session between requests. In this case, that state is checkbox values.
You have a choice to make first: do you want to store the data on the client (in the browser) or on your server?
Server Side
You can store this state on the server side with or without a "database" depending on how pedantic you want to be about the term.
If what you want is to avoid configuring an SQL RDBMS, you might find that the built-in storage options from most Java Servlet containers will work. In Tomcat, you can just use your Session objects as normal, but configure a "File Based Store" instead of a "JDBC Based Store." This will store session data to disk in files. Alternatively you can use StandardManager which uses in-memory storage, but does not persist session state across restarts.
Put simply, these will create a Java Map for each JSESSIONID issued by your server, and then keep the maps in memory, on disk, or in a JDBC database. For more information see: https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html
Client Side
Here you have a few options as well. The driving factor is what level of browser you wish to support. If you can tolerate restricting your users to those who use a browser with HTML5 web storage and JavaScript enabled, things are pretty easy. If not, you can accomplish the same thing with a cookie.
The big downside to client-side storage is trust. Users (or software on their computer) can modify client-side storage. This goes for cookies, localStorage, and sessionStorage. Many developers forget this and introduce security vulnerabilities because of it. If this is for a real production web application, you'll want to wrap your state in an authenticator.
Here's a the first in a three article series on a way to convince your servlet container to put session state into cookies in a way that is transparent to your servlets. It is missing authentication, but you can add it by following guidance such as this bit from Rob Winch.
Now What?
Ok. You've decided to use client- or server-side storage for your checkbox values. Now what?
A simple (usually wrong) option is to store the checkbox input names and values in a map:
{"boxFoo": true,"BarBox":false}
The reason this is usually wrong is that it fails to distinguish which form your user was visiting. It means that if you apply this strategy to more than one form on your site, you'll have to worry about name collisions.
The next evolution is to have a structure keyed by form name and then field name. This would be a map like the following:
{ "formA": {"boxFoo": true,"BarBox":false},
"formQ": {"checkAlpha":true,"BetaCheck":false } }
This works, but will have annoying behavior when your users use multiple tabs. You can make that behavior more predictable for your users by using per-tab identifiers -- at the expense of space in your session object -- or by using AJAX to keep the fields in sync -- which has its own perils. Or you can do what most people do an just assume that the last submitted form overwrites the state from all previous ones, tabs be damned. That's much simpler to code, but more annoying to users.

I can propose some ways :
send http params (in hidden field) with check boxes flags which must stay checked in each new page requested by your application . You can factorize it with a function but it stays cumbersome to do.
store the check boxes marker flag in the http session. If the check boxes must stay checked in all the life of your user, it may be a suitable solution. Use may use a backing bean session for it as you use JSF.
Nevertheless, store the minimum of information in it.
store the information in a shared applicative cache to retrieve it. In this way, you stay stateless and you have not the drawback of the session if you use clustering in your servers.
There is maybe better as alternative.

You have to bind the value with a backing bean. As long as the backing bean is having the appropriate scope it will be retained on the page when you navigate to it.

Save Form Data for when user returns

Here is my problem...
We have a very large Form with many inputs and check-boxes, the problem happen when the user's pc disconnects he then need to restart the form.
After doing many Google searches I've found a few solution but i have no exp using any of the following and would like to know which solution is better used.
Save a session with post variables so that when user returns his data would be saved. (problem is with session destroyed when browser leaves page.)
Save the post variable to a temporary table, and if host name of user is there to populate the form to continue where he left off. (Probably the simplest way)
Session Storage and Local Storage, Both of these seemed like a good alternative but haven't seen any examples or any docs on how this can be used to populate forms.(No Exp with this.)
I'm thinking of using the second option and just wiping that table after 1 hour but would like to know which is better in terms of what is more widely used for this solution.
Thanks

you can send the data with the onBlur on the textfields with ajax post to a php file which writes them into the session or a coockie or a database.
Session ends when the Browser(not the tab) has been closed. Coockie must be aktivated by the user. So i think the temporary table is the best solution for you.

How to safely store and access user session data

I am currently learning about security aspects in web applications.
My application used to identify the current user by a cookie which was created on successful login. It contained the user's id. Every time the user has made a request to the database, my application would use that id to select only those results that were associated with this id.
However, as I learned, it would be no problem at all to simply change that cookie's value and therefore get access to another user's data.
My issue now is: how would I safely store such data and make it available to both PHP and Javascript?
I thought of HTML5 sessionStorage, but that would be vulnerable too.
My second thought was to store it by PHP only in a $_SESSION variable, but then I could not access its value via Javascript.
I feel like I can not wrap my head around the basic concepts of how to create a secure and functional user-management system.
Any help will be appreciated.

I would store the user id data only in the session. Why do you need cookies?
To communicate between JS and PHP use ajax. Best library for this is jQuery
.

Simple solution:
Add a userKey field to the database.
When user logs in, generate a random unique string and save it in DB
Save this string in cookie. Save user ID in cookie.
On the next visit, select from the database user with the corresponding userKey and ID.
It is somewhat secure, because the string is random, so only bruteforce helps.
Longer the string - harder to bruteforce.
The solution is simple, it can be upgraded by using crypting of ID, checking IP, etc.