Context
When casting from Google Chrome and using the session listener it's possible to join an already created session, this works well when the session is created from chrome, and if the autoJoinPolicy was set to ORIGIN_SCOPED it even works from a different tab.
The problem
If another device created a session the sessionListener handler doesn't fire, so I'm not able join the created session.
Between devices (android, ios) is possible to detect sessions, that the same behavior I would like to achieve with chrome, is this possible?
You can connect to other sessions as well, it shouldn't be necessarily your own session. For example, you can check out the CastVideos-android and CastVideos-chrome sample apps and start a cast session with Android and then connect to that with the chrome app.
Related
I have connect multiple android devices to the same WiFi network but internet connection is not working. I want to sync data between all devices. Is there anyway to do the data synchronization on local network without internet ? in short I want to sync data between devices using local network.
Sure! It's not trivial though.
If you're looking to do this without using a "static" server or database or similar on the local network,
you'll need a way for the devices to be able to discover each other (the easiest is manually, i.e. by entering an IP address)
listen to network requests – on one device if you're looking for a star/server-client topology, or on all of them if you're looking for a mesh where all devices sync with all of them
have the devices talk to each other to sync data as required.
I have a web app that uses a cookie as an access token (to let users stay logged in after refreshing/closing the site/app). It works perfectly on desktop but when I try to use it on my Android phone (installing it via Chrome), for some reason it says that I'm not logged in which means it wasn't able to load the access token.
Why is this happening? Is there a difference between how cookies are handled in the browser and when starting a PWA as a standalone?
Also two little side questions, 1, is there a way to debug a PWA that's added to the homescreen (using some sort of remote debugger) and 2, would it be a security risk to use localStorage for storing the access token instead of a cookie? I realize neither is particularly safe but I read that cookies are slightly better for this sort of thing. localStorage works just fine when starting as a standalone
I'm currently doing a project with the web bluetooth in js and I wonder if there is a way to save the device object and automatically connecting to it instead of choosing the device in the pop up every time.
I've tried saving the device in the local storage and tried to get it in the cookies but they both failed.
There is a way, but it implies enabling some Chrome feature flags on a Chrome 85+
You can have a look at the documentation.
To sum it up, after enabling those two feature-flags in chrome://flags :
#enable-experimental-web-platform-features
#web-bluetooth-new-permissions-backend
The Web Bluetooth spec will be updated with the algorithm for getDevices(). The devices returned by getDevices() may contain devices that are not currently in range and connected. The BluetoothDevice::watchAdvertisements() API can be used to detect when Bluetooth devices come into range of the Bluetooth radio. Then calling BluetoothRemoteGATTServer.connect() should resolve successfully if the device is able to be connected to.
Using navigator.bluetooth.requestDevice(), I can access bluetooth devices I've already set up a pair with using native OSX bluetooth pairing, but no previously-unpaired devices appear, even when their attributes match my generic query. Available devices show up in a Chrome modal requesting user consent to pair, but the only device that shows up is the one I've already paired with.
Am I misunderstanding the intended use case here, or is there another way to establish a connection with a nearby (previously unpaired) device from Chrome?
Docs: https://webbluetoothcg.github.io/web-bluetooth/
(See Example 2)
function bluetoothConnect() {
navigator.bluetooth.requestDevice({filters: [{services: ['generic_access']}]})
.then(device => {console.log(`Connected to: ${device.name}`)})
.catch(console.error);
}
First, Mac OS X is not yet fully implemented as we speak. Only discovery and GATT server connect/disconnect are working for now. See the Chrome Implementation status at https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md. Check out Chrome OS, Linux and Android M (Android Lollipop workaround).
Regarding your specific issue, I believe that generic_access is not broadcasted by a nearby BLE device but is found because you've already paired (cached) this device. If your device is named "foo" for instance, you can go to https://googlechrome.github.io/samples/web-bluetooth/device-info.html and fill "foo" as the Device Name and hit "Get Bluetooth Device Info" button.
I would recommend you give a try to all Web Bluetooth samples at https://googlechrome.github.io/samples/web-bluetooth/index.html as well.
To complement the other answer, please be aware of the Chrome's chrome://bluetooth-internals tab/tool. This tool can not only list available devices and their services (which I don't think you can do with the Web Bluetooth API unless you requested the services in optionalServices or filters/services) and the characteristics of those services.
In the device list, there is a Forget button which becomes active once you connect to the devices GATT server using the Inspect button. This should allow you to full unpair and pair again in cases where you need to test the flow end to end.
Edit: Actually after doing some experimentation around this, the device still remains paired even after using the Forget button. Probably a bug in Chrome, however, the cache of the paired devices seems to be per-profile. This means the real answer is to:
Use the Incognito mode and in there the pairing flow will initiate from the get-go for each new Incognito session.
So, I'm building a Guest Internet portal for a public hotspot in a hotel. This means the portal is served through a Network Access Gateway (a Nomadix) that redirects all outgoing traffic to the portal page. The portal needs to be able to set cookies on the browser so that Guests can be automatically logged back in after they idle timeout.
The Problem:
iOS4+ and OS X (10.7+) Devices have a feature called Captive Network Support. This feature continuously scans for Wifi SSIDs, connects to them, and curls http://www.apple.com/library/test/success.html to see if the device is connected to the internet. If it doesn't get the Success response, these devices pop open whats called a Captive Network Portal. This portal is not a true version of Safari Mobile and you cannot save cookies on this browser.
I would like an authoritative answer to the following question:
With client-side javascript/markup can I?
A) Save cookies within the Captive Network (popup) browser
B) Prevent the Captive Network browser from popping up in the first place without whitelisting apple.com
This is kinda the wrong site in the StackExchange network for sysadmin stuff; you may wish to try ServerFault. In my experience as a user, there are WiFi portals out there that manage reauthentication without cookies; perhaps ServerFault can help you find such.
That said, there's one possible solution in terms of iOS client-side development: There are CaptiveNetwork APIs which allow a third-party app to inform the system that it's assumed responsibility for authenticating to particular SSIDs, suppressing the web sheet. It's likely not a desirable solution, since it requires your users to install an app, but it's there.
You could try serving "http://www.apple.com/library/test/success.html" locally when ever an iOS device is detected. This will make the CNA not pop up and then the user could login through mobile safari, in which you can save cookies.
iOS 14 has a new API for work with a captive portal. Btw, Android supports it too