#sessionStorage

[apastebin]

[Adobe Analytics|DTM] Previous pageName

If you want to save the previous pageName via DTM without a Plugin (getPreviousValue), you can use Session Storage. Two Pageload Rules are needed.

First PLR: - Trigger Rule at “DOM Ready” - Rule Condition: Path “.*” (regex enabled) - Custom Code “None-Sequential Javascript”:

if(typeof(Storage) != "undefined") { if (typeof(s) !== "undefined") { sessionStorage.pagename = s.pageName; } }

Second PLR: - Trigger Rule at “Bottom of Page” - Rule Condition: Path “.*” (regex enabled) - Rule Condition: Custom:

if(typeof(Storage) !== "undefined") { if(typeof(sessionStorage.getItem("pagename")) != "undefined") { var prevPageName = sessionStorage.getItem("pagename"); _satellite.setVar("previousPage",prevPageName); return true; } }

- Adobe Analytics: prop2 set as %previousPage%

There you go, the previous pageName is implemented.

[dragoni]

Differences between sessionStorage and localStorage

Each window/tab gets its own copy of a sessionStorage object which allows for the storage of key/value pairs that are specific to the current window.

One thing to note about sessionStorage objects is that if you open a window from the current window, the sessionStorage object that is created for the new window is a clone of the sessionStorage object of the window that opened it. The sessionStorage objects are no longer in sync after the new window has been opened but this is something to be mindful of if you find values in the new window's sessionStorage object that you were not expecting.

With localStorage, each origin (SomeFreeWebSiteHost.com for example) gets a single copy of a localStorage object that is shared by all windows/tabs from that origin. This has the advantage that multiple windows of your web site/web application can easily share data but that ease of sharing could result in security concerns if you are not aware of how this object is shared.

The sessionStorage key/value pairs exist only while the browser is open. The moment you close the browser, the sessionStorage key/value pairs for your window are cleared.

With localStorage, the key/value pairs stick around even if the browser is closed and re-opened.

[angulardevelopment]

How to Store temporary Form Data in an Angular and SessionStorage ☞ https://morioh.com/p/6c30d73e43c8

#morioh #sessionstorage #angular

[webmarks]

jStorage is a cross-browser key-value store database to store data locally in the browser - jStorage supports all major browsers, both in desktop (yes - even Internet Explorer 6) and in mobile.

[htmller]

Web Storage is a new HTML5 API offering important benefits over traditional cookies. Although the specification is still in W3C draft status, all major browsers support it already. This means you can start using the API’s sessionStorage and localStorage objects and enjoy their benefits.

[search5]

Apigee의 기본 UI 변경

Apigee는 구글에 인수된 솔루션으로 API 프록시 개발을 위해 별도의 사이트가 존재한다. https://apigee.google.com 근데 구글은 이렇게 서브 도메인으로 독립되어 있는 솔루션의 UI를 GCP 콘솔로 합치려는 시도를 꾸준히 하고 있다. Apigee도 그렇다. 또 한 편으로 Apigee도 프록시 개발을 위한 화면이 Classic UI와 New UI가 있는데 각각 쓰기 좋은 부분도 있지만 확실한건 New UI가 기본값이다. 그런데 New UI에서 Class UI로 바꾸고 나서 다시 New UI를 클릭하면 GCP 콘솔로 이동해버린다… 이 상황을 해결하려면 브라우저의 LocalStorage에 ENABLE_PROXY_EDITOR_v2_BY_DEFAULT의 값을 true로 바꾸고 다시…

[syakuis]

js sessionStorage

http://jsbin.com/qelilih/edit?js,console

sessionStorage.setItem('good', null);

const good = sessionStorage.getItem('good');

console.log(good, typeof good);

/** "null" "string" */

sessionStorage.removeItem('good');

const good2 = sessionStorage.getItem('good');

console.log("-------------------------------------------- //");

console.log(good2, typeof good2, (good2), !good2); // null

/** null "object" null true */

[sahijankari]

ngStorage localStorage and sessionStorage done right for AngularJS

ngStorage localStorage and sessionStorage done right for AngularJS

ngStorage localStorage and sessionStorage done right for AngularJS

An AngularJS module that makes Web Storage working in the Angular Way. Contains two services:$localStorage and $sessionStorage.

Differences with Other Implementations

No Getter ‘n’ Setter Bullshit– Right from AngularJS homepage: “Unlike other frameworks, there is no need to […] wrap the model in accessors methods. Just plain old…

[developpement-facile-blog]

Comment utiliser le stockage local et persistant dans le navigateur avec HTML5

Et on continue à monter en puissance dans votre apprentissage du langage HTML5. Profitez, vous aussi, d'une nouveauté HTML5, à savoir le stockage persistant de données en local, directement dans le navigateur. Tout est dans la formation ci-dessous. Afficher le texte de la vidéo Comment Téléchargez le code source complet sur : http://www.programmation-facile.com/utiliser-stockage-local-persistant-navigateur-html5/

[dragoni]

The core argument used against Web Storage says because Web Storage doesn't support cookie-specific features like the Secure flag and the HttpOnly flag, it's easier for attackers to steal it. The path attribute is also cited. I'll take a look at each of these features and try to examine the history of why they were implemented, what purpose they serve and whether they really make cookies the best choice for session tokens.

...

The HttpOnly flag is an almost useless XSS mitigation. It was invented back in 2002 to prevent XSS being used to steal session tokens. At the time, stealing cookies may have been the most popular attack vector - it was four years later that CSRF was described as the sleeping giant. Today, I think any competent attacker will exploit XSS using a custom CSRF payload or drop a BeEF hook. Session token stealing attacks introduce a time-delay and environment shift that makes them impractical and error prone in comparison - see Why HttpOnly Won't Protect You for more background on why. This means that if an attacker is proficient, HttpOnly won't even slow them down. It's like a WAF that's so ineffective attackers don't even notice it exists. ...

One major difference between the two options is that unlike cookies, web browsers don't automatically attach the contents of web storage to HTTP requests - you need to write JavaScript to attach the session token to a HTTP header. This actually conveys a huge security benefit, because it means the session tokens don't act as an ambient authority. This makes entire classes of exploits irrelevant. Browsers' behaviour of automatically attaching cookies to cross-domain requests is what enables attacks like CSRF and cross-origin timing attacks. There's a specification for yet another another cookie attribute to fix this very problem in development at the moment but for now to get this property, your best bet is Web Storage. ... Unlike cookies, web storage doesn't support automatic expiry. The security impact of this is minimal as expiry of session tokens should be done server-side, but it is something to watch out for. Another distinction is that sessionStorage will expire when you close the tab rather than when you close the browser, which may be awesome or inconvenient depending on your use case.

[webmarks]

In many projects there comes a time when you’ll need to store some data off-line. It may be a requirement or just an improvement for your users, but you have to decide which of the available storage options you will use in your application. This article will help you choose the best one, for your app.

[hackily]

Queueing Commands in LocalStorage

I've been using queues a lot lately in my front end code. They've been great for breaking apart complex actions, and providing some stability to volatile operations.

A real-life example from G2Crowd is in our metrics gathering code. When a user interacts with our interface, we send send ajax calls to our analytics system. These metrics are used to track adoption of our features, and help us respond to problem areas in the application.

This can be tricky, because the events that we are tracking are pretty volatile. For instance, when a user clicks on a link, the browser will tear down the current page and cancel any active ajax requests. As a result we end up dropping quite a few data points.

The Queue

Enter the queue. Instead of directly running our function when the user clicks on the link, we can instead push some data into a list that will be processed later. Not only is this a great tool for pushing complex interactions into the background, it is also good for dealing with unexpected failures and timeouts.

With a little bit of planning, our queue can even be serialized into LocalStorage or Cookies. This means that our code will work across page refreshes!

So let's start with the queue. A queue is simply a first-in-first-out list, so we'll just wrap up an array with an 'enqueue' and 'dequeue' method, and a few hooks for convenience:

This basic queue is pretty easy to use:

The Queue Manager

So now we have our list; we can now go about creating some handlers to process the list for us. Let's create a queue manager that will deal with each item in the list in order.

This module is a bit longer than the previous one, and may be a little daunting. After the full listing, I will break it down function by function.

First, the module takes two parameters; a queue that it will be managing, and a callback function for processing each individual entity in the list:

The 'flush' function is what we call to start clearing out the queue. We want to make sure that we can always call this function safely, so we use a flag to avoid flushing multiple times:

The 'process' function is what does most of the work for us. If there are any items in the list, then we call our handling callback with everything needed to process the current item. Otherwise we stop flushing and clean up.

The 'next' function is called to advance the queue forward, and start working on the next item. We pass this function to our callback, to give us a way to complete items asynchronously.

The 'fail' function will simply try to process the current item again. Notice that we keep count of failures, and pass the number to our hooks. This gives us an easy way to manage bad queue values if we need to later. This function is also passed to our handler callback.

In order to kick off our queue processing, we use the 'onEnqueue' hook to begin flushing as soon as any item is added to our queue. Notice that we are careful to avoid overwriting any previous onEnqueue handlers that have been assigned:

And finally, we return our public interface. We provide direct access to the flush call, as well as a few hooks:

Now that we've walked through the code piecemeal, it should be relatively easy to see how to consume it. We simply pass in our queue, and call the 'next' or 'fail' functions within our callback to advance the queue forward:

Using the Queue to send AJAX Requests

Now let's get back to our analytics logging. Let's say that our analytics code just sends an ajax request to an endpoint:

With our current queue manager, we can create an analyticsEvents queue to hold all events that we want to record. Our manager will be able to send the ajax for us, and will also guarantee that the ajax calls finishes successfully. In order to do this, all we have to do is pass the 'next' and 'fail' functions directly to the ajax handlers:

Now our logEvents function simply pushes items into the queue. If the ajax call fails for whatever reason, we'll just try again, and once we've completed logging an event we'll move on to the next one.

Storing the Queue in LocalStorage

So what happens if the page is refreshed? As the code currently stands, we would lose our queue, as well as any data points that we had hoped to capture.

Thanks to LocalStorage, this is very easy to deal with. We can use the hooks on our queue to save a copy of the list every time it is modified. The queue will be loaded from LocalStorage when the page is ready:

So now we can pass this persistent version of our queue into the existing queueManager object:

If the ajax call fails or gets canceled, then it will not be removed from the list. If the user refreshes the page, our code will retrieve the stored queue from localStorage and try again.

Regarding using LocalStorage directly like - this will fail across some browsers. We use a very simple polyfill on our site to improve compatibility.

Where to from Here?

There are a few additions that we could add to our queue manager to clean it up even further. In my production version of this code, I set up a timeout to call 'fail()' if an item is taking too long to process. We also set up a retry limit, so that after X number of failures we continue on to the next item. Finally, we catch exceptions from processing the queue directly in our manager, so that a single bad item won't sabotage our entire list of commands.

The beauty of the queue is that these relatively complex interactions are split off into the queue manager. This makes them easy to test and reason about directly, without becoming tangled up with our business logic.

[hilios]

Storage.js is the result of the pain using the default localStorage and sessionStorage api interface and possibilities. Inspired by Redis, I created a wrapper with the same api methods but localStorage as the storage container.

[dragoni]

sound advice

The Always and Never of Web Storage

ALWAYS:

Always  validate, encode, and escape user input before placing into localStorage or sessionStorage

Always  validate, encode, and escape data read from localStorage or sessionStorage before writing onto the page (DOM).

Always  treat all data read from localStorage or sessionStorage as untrusted user input.

NEVER:

Never store sensitive data using Web Storage: Web Storage is not secure storage. It is not “more secure” than cookies because it isn’t transmitted over the wire. It is not encrypted. There is no Secure or HTTP only flag so this is not a place to keep session or other security tokens.

Never use Web Storage data for access control decisions or trust the serialized objects you store here for other critical business logic. A malicious user is free to modify their localStorage and sessionStorage values at any time, treat all Web Storage data as untrusted.

Never write stored data to the page (DOM) with a vulnerable JavaScript or library sink.  Here is the best list of JavaScript sinks that I am aware of on the web right now.  While it is true that a perfect storm of tainted data flow must exist for a remote exploit that relies 100% on Web Storage you must consider two alternate scenarios. First, consider the evil roommate, unlocked, unattended, or public computer scenario in which a malicious user has temporary physical access to your user’s web browser. The computer’s owner may have disallowed a low privileged user from installing malicious add-on but I’ve never seen a user prevented from making a bookmark. Second, don’t ignore the possibility of improper Web Storage usage allowing escalation of another vulnerability such as reflective cross-site scripting into persistent cross-site scripting.