For such a big honkin' button on the main Glimpse control panel, it's surprising that "Set Glimpse Session Name" brings up only 7 results on Google (13 if you drop "Set").
Whatever it is, it sounds important. So what is a session name in Glimpse, and what does setting one do?
The Session name can help you to make a distinction between different clients. By default the browser name is used, but if you want to make distinction between different sessions in the same browser, then setting the session name will help you with that.
The printscreen I included will show you the different clients that were connected through the History tab, all requests are grouped per client. The IE 10.0 or Chrome 28.0 are defaults determined from the browser being used. The cgijbels is the one I set myself while using the same browser that initially indicated Chrome 28.0
I hope that answers your question
Related
I have created a simple embedded public app in shopify using node js for test purpose. It works properly .
while i opened two stores in same browser's different tab . I faced the issue of session clash.
For example shop domains store1.myshopify.com and store2.myshopify.com were opened in same chrome browser. First i opened store1 it worked properly . Then i opened store 2 it changed the store1 app's session values. Now in both stores app displayed store2 record.
I dont know how to handle this . Please guide me how to resolve this issue.
It is simple. When you get an incoming request, you can compare the active session store name to the incoming store name. If they differ, you have to close the session, and re-open it for the new store.
Since your App issues a single cookie key for all shops, any open browser tabs would share this, hence the need for you to close/open connections based on the information coming in from the tab.
Note that when you close one session, it means that when you use the tab with that now closed session again, you'll re-authenticate. This means your customer may or may not send in the shop name (especially if your App views have XHR calls without the shop name as a parameter). So be careful there. That can be tricky to handle well.
I added Google Analytics to a Chrome Extension. It is reporting events correctly as well as recording popup page views. When the extension is reloaded it correctly records a view of background.html which I explicitly call.
Problem: Despite the extension having a persistent background.html page, "Active Users" in the Real-Time section of GA shows 0. I would like to be able to see the # of concurrent users of the extension at a given time. Is there a way to do it?
Possible Solution? - When I open the popup it displays an active user for some number of minutes before dropping back down to zero. Do I need to create a heartbeat function of some kind that pings GA every X minutes to keep a user active. It seems a big "chatty" to do that.
Is there a better solution?
Please note, this question is not about client-server sessions. It's about Chrome session.
I'm reading this article about tabId and it states that:
Tab IDs are unique within a browser session.
What is browser session here? Does the session begin when I open a browser and ends when I close it? Is there a way to track tab across sessions?
What is browser session here? Does the session begin when I open a browser and ends when I close it?
That's correct. It means a tab will preserve its ID only until you close the browser.
Even if the browser is configured to reopen the previews windows on startup, they will all have a different tab ID and window ID.
Is there a way to track tab across sessions?
Yes, with the tabs permission! Mostly.
The IDs will be different but you can query all the open tabs and windows and you will receive the position of a tab in a window (e.g. first tab in window 2) together with its URL. You'd have to regularly query and save this data via chrome.storage.local.set()
You can then compare this piece of information to the data you stored before closing the browser and match them to each other. For example you receive tab on position 1, with URL xyz, in a window with 3 other tabs, you can find a tab with the same details in your storage.
The "mostly" part: If the user has 2 windows with 1 tab, both pointing to the same page, you won't be able to tell which is which.
I have need to communicate between two iframes of the same domain, which live inside a parent page on a different domain that I have no control over.
This is a Facebook app and the basic layout is this
apps.facebook.com/myapp
L iframe1 (src='mysite.com/foo')
L iframe2 (src='mysite.com/bar')
I need frame1 to talk to frame2, but in Opera I can't access window.parent.frames['frame2']
to do the usual cross-domain methods (updating location.hash for example)
Is there an alternate way to accomplish this in Opera?
Thanks for your help in advance
Did you try using HTML5 web messaging. It is quite well supported currently by recent versions of browsers.
iframe.contentWindow.postMessage('Your message','http://mysite.com');
The postMessage property will need the origin http://mysite.com.
Generally no. Same Origin Policy denies you the possibility of communicating upwards to the parent, which would be necessary to then step downwards to the other frame. This is true in any browser.
If the parent document has given your frame-to-be-contacted a unique name, there is a limited form of communication possible with it by getting the user to click a link with href="otherurl#message" target="name", which will navigate the target frame by changing the hash without reloading the page, as long as the URL matches exactly. In Mozilla you can also do this with a form target, allowing you to script its submission (since link clicking cannot be automated), but not in Opera. Probably not much use... don't know if FB gives you a frame target name in any case.
You can make a communication channel between scripts in the same domain by using cookies(*): one script writes a session cookie, the other script polls for changes to document.cookie to find messages in it. But it's super-ugly and requires some annoying work to control signalling which messages are meant for whom when there are multiple documents open simultaneously. And there are further limitations for cookies in third-party frames (you will probably need to write a P3P policy to get IE to co-operate).
(*: or, presumably, HTML5 web storage, where available.)
As others have said, use window.postMessage. But instead of using window.parent.frames['frame2'], try window.parent.frames[x] where x is the position in the node list of the other iframe.
You can see an example of doing this across origins here: http://webinista.s3.amazonaws.com/postmessage
It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.