While calling WL.Client.logout, it asks for two parameters.
Realm Name
Options
The Options parameter does not provide much information if I look into the IBM MobileFirst knowledgecenter documentation. although From one of the sample it shows one of the options be onSuccess. what can be the other options for this API. Can there be onFailure option as well. If yes, under which circumstance that callback will be executed. As infocenter does not provide much on the options parameter for WL.Client.logout, I wanted to ask this question here.
WL.Client.logout's method signature is: WL.Client.logout(realm-name,{onSuccess: ..., onFailure});
So yes, you can use onFailure there.
When using logout, its onFailure will be called in cases such as:
There is no Internet connection
There is Internet connect but the server is not reachable
Probably if the realm does not exist (double-check that)
Related
A user of my app reported an issue today about authorizing the user with Google (using OAuth 2.0). So far the application was opening a new BrowserWindow (node integration disabled, session is separated from the main application). You can see the implementation here since the library is OSS. I am using this to authorize the user to access application data on Google Drive.
Today after logging in I see the following message:
This browser or app may not be secure.
Try using a different browser. If you’re already using a supported browser, you can refresh your screen and try again to sign in.
The learn more link has a section for developers. This section has 2 links. One is how to upgrade the application to PWA. Because the application is an API testing tool it won't be possible to run it in a web browser.
The second link points to a document describing how to migrate to authorization for native application. However described flow requires authorization_code grant. This means I need to include OAuth secret into my application. Electron application, however, is still web application and there's no notion of compiling sources. I would expose client secret to the public which is not secured. Potentially I could build a server application to support it but the app is OSS project. It does not have funding to run a server for authorization.
My question is now how should I implement OAuth 2 for Electron application then. I can't use PWA's and server authorization flow (code grant) is far from ideal in this case.
As Paweł explained, changing the user agent will do the trick. However, you can easily set the user agent by passing an object when loading the URL
win = new BrowserWindow({width: 800, height: 600});
win.loadURL(authUrl, {userAgent: 'Chrome'})
I have tested it and it worked like a charm
Warning: This answer relies on changing the browser's user-agent. As of Jan. 2021, Google disapproves of this and warns not to do this (see EDIT4). Use at your own risk!
The other answers didn't work for me (in Electron 9.0.5), but I eventually found this, which worked:
app.on("ready", ()=> {
session.defaultSession.webRequest.onBeforeSendHeaders((details, callback) => {
details.requestHeaders["User-Agent"] = "Chrome";
callback({ cancel: false, requestHeaders: details.requestHeaders });
});
CreateMainWindow(); // your regular code to create root browser window
});
EDIT: Two other approaches, which I haven't tested, but which may also work:
app.on("ready", ()=>{
session.defaultSession.setUserAgent("Chrome");
...
}
app.userAgentFallback = "Chrome";
EDIT2: Trying again sometime later, approach #2 did not work, but #1 still did. Haven't tried #3 yet.
EDIT3: Trying again later still, it seems that none of these workarounds are needed anymore! Google appears to accept sign-in popups from Electron apps again, without modifications to the user-agent. (odd that they'd revert this; perhaps I just did something wrong in my re-attempt)
EDIT4: While approach #1 still works atm, I recently found this blog post: https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html Apparently Google is restricting usage of Google sign-in in non-standard browsers (which presumably includes Electron) starting in Jan. 2021, and warns developers not to modify their browser's user-agent (which all three of the possibilities I mention do). Use at your own risk! (they don't make clear what outcome will result, but for my own use, I'm opting to use the alternative shown below from now on)
As an alternative to using a Google sign-in popup in your app (which some might be wary of, since Electron apps could in principle insert code into the popup to read the raw password -- not that it matters that much, since Electron apps could just install keyloggers or the like anyway), you could instead open a tab in the user's regular external browser, pointed to a special page that triggers a sign-in popup there, and then just sends the credentials to your Electron app afterward.
Instructions can be seen here (approach 3): https://stackoverflow.com/a/64328193/2441655
After taking a wild guess I decided to alter the user agent string and to remove application name from it as well as Electron/ with version. After this alteration it started working again.
Example implementation:
const win = new BrowserWindow(params);
let ua = win.webContents.userAgent;
ua = ua.replace(/APPLICATION NAME HERE\/[0-9\.-]*/,'');
ua = ua.replace(/Electron\/*/,'');
win.webContents.userAgent = ua;
This assumes the application is using symver and no pre-release tags. Otherwise you would have to tweak the regexp a bit.
I am new to web-app development and the reSolve framework I am using for the backend (javascript). Since the application will have multiple users with different authorizations, I am using the Authentication and Authorization module like described in the documentation plus some lines from the shopping-list-advanced example.
The problem I am facing now is, how to make the HTTP-request in order to actually authenticate a user (register/login and also, logout)?
Since I couldn't find anything in the documentation, I've been trying a POST-request to http://localhost:3000/register but it always just returned Access error: POST is not addressable by current executor. What am I missing?
Another problem, or rather unclarity: In the example shopping-list-advanced what is "ROOT_JWT_TOKEN" and what is it used for?
Thanks a lot in advance.
I found it myself - at least the general path for the HTTP-request (see marked comment in picture):
Picture was taken from: https://github.com/reimagined/resolve/tree/master/packages/modules/resolve-module-auth
According to the WL official document, all the authentication happen as the following scenario.
a client request for a protected resource
server invokes the client side ChallengeHandler::handleChallenge()
At the client side, in the handleChallenge(), it would invoke
ChallengeHandler::submitAdapterAuthentication
My question is
I have tried another alternative. Call the following directly.
ChallengeHandler::submitAdapterAuthentication
For now, everything works fine for me. And I wonder if there's any side effects of doing this
While the documentation indeed states what you wrote...
Yes, this type of "pro-active authentication" should be fine to work with none the less.
I'm looking to write a philips hue service that needs to allow users to register their hue bridge with my service. This service would change the color of bulbs based on an event. I'm aware that I can use IFTTT but in this scenario, I'd like to not use IFTTT and I'd like to register my website with philips hue's apps.
Any idea how I can do this? Your help is very much appreciated. Thanks!
EDIT: Not sure why I was down voted but I definitely did do my research. I looked on philips hue's developer website and couldn't find anything that was explicit on their APIs. I also looked through the iOS SDK and didn't see any methods that would trigger the pairing routine for remote devices. So far, the only example I have of this working (outside of Philips' products is the IFTTT service, which allows for an entry to be added into the 'My Apps' section).
TLDR: I wrote an API: https://github.com/jarvisinc/PhilipsHueRemoteAPI
I answered this question on my technical blog (http://blog.paulshi.me/technical/2013/11/27/Philips-Hue-Remote-API-Explained.html), which I will post here:
The question actually comes as two part:
Authentication
Remote Control
Authentication
I haven't figure out a reliable way to do authentication automatically. The following procedures needs to be automated: The idea is to fake as official iOS APP which has the ability to control remotely when enabled. We will need to get BRIDGEID and ACCESSTOKEN to pass the authentication step for remote control.
Find your BRIDGEID from https://www.meethue.com/api/nupnp. (or in My bridge page on the meethue website and by clicking on "Show me more")
Get ACCESSTOKEN
www.meethue.com/en-US/api/gettoken?devicename=iPhone+5&appid=hueapp&deviceid=**BRIDGEID**
Right click on "BACK TO THE APP" and write down ACCESSTOKEN inside the link it redirect to
phhueapp://sdk/login/**ACCESSTOKEN**
Basically it is a hack to get your access token. You fake your app as the official iOS Hue App, and ask for access token that way. I am not sure there is an easier way out there, if you do know one, please do comment below.
You can potentially automate it by doing simulated log-in session and grab the the ACCESSTOKEN by scraping the page content. But I consider it highly unreliable because any change to the official page will likely break it.
I wrote this script that allows the automation of getting ACCESSTOKEN as of today, but I don't guarantee it will work tomorrow for the reason I explained above :P
Currently, this OAUTH process only works with official apps. There might be a slight chance that they will open it to other 3rd party apps.
Remote Control
Once authentication is done, this part can be done automatically. There are 2 known private endpoints for sending control command and getting all the status related to the hue bridge.
Sending Command Endpoint:
POST https://www.meethue.com/api/sendmessage
Getting Status Endpoint:
GET https://www.meethue.com/api/getbridge
Sending Command Endpoint
URL: https://www.meethue.com/api/sendmessage
Method: POST
URL Parameters:
token=**ACCESSTOKEN** (which you obtained earlier)
Request header
content-type=application/x-www-form-urlencoded
body
clipmessage={ bridgeId: "**BRIDGEID**", clipCommand: { url: "/api/0/**APIENDPOINT**", method: "**METHOD**", body: **JSONCOMMAND** } }
BRIDGEID is the same one you obtained earlier
APIENDPOINT the same as official API /api/<username>/*** by removing /api/<usename>/ part
METHOD PUT/GET/POST/DELETE the same 4 method as official API. Despite GET really doesn't work since all response from the Sending Command Endpoint is 200 explained in the following part, while DELETE is not tested
JSONCOMMAND The actual command body for example {"on":true}
Getting Status Endpoint
URL: https://www.meethue.com/api/getbridge
Method: GET
URL Parameters:
token=**ACCESSTOKEN**
bridgeid=**BRIDGEID**
Request header
content-type=application/x-www-form-urlencoded
Limitations
Current limitation is you cannot immediately know from the response whether your control command succeeded like the official API. All the response you get from calling the Sending Command Endpoint is pretty much always <200> if you are doing it correctly. But you can always pull all the status related to the Hue bridge from the Getting Status Endpoint.
Remote Control API
I wrote Philips HUE Remote API to specifically solve the remote control problem.
Enjoy :)
Paper
For full documentation please refer to this excellent paper:
Hacking Lightbulbs: Security Evaluation of the Philips Hue Personal Wireless Lighting System by Nitesh Dhanjani
I did some investigation by following the steps of #paul-jianer-shi however the access token are not shown in the generated HTML.
I think the Hue Portal has been updated and removed the way it potentially shows the access token.
I wrote a blog post about doing Remote Hue operations by reusing the access token of another application, like IFTTT. The main change is how to get your hands on that access token. The token in shown in the 'My Apps' section of the Hue Portal. Check the (De-activate) link. It contains the access token.
Next step will be to let Hue Portal trust my own app.
Philips plan to make the remote API available to 3rd parties(it's already used by IFTTT and meethue.com).
There is currently a form on the developer website to request an early access(must login):
http://www.developers.meethue.com/content/remote-api
I want to access my pentaho user console without login.Could it happen?How?
What i mean user console is page thats appear after login.Like url below:
http://localhost:8080/pentaho/home
I already follow this tutorial but i cant continue to the 3rd step.And the error said
The requested resource () is not available.
Anyone have suggestion?
That tutorial may be slightly dated. Here are the latest instructions from The Pentaho Security Guide: http://infocenter.pentaho.com/help/index.jsp?topic=%2Fsecurity_guide%2Ftask_removing_security.html
I have not enabled anonymous access myself, but have made other customizations to roles and the ACLs. I reviewed these instructions and they seem reasonable and complete.
Good luck!
There is an option following the steps found in this guide: https://help.pentaho.com/Documentation/6.1/0P0/150/040
The documentation might result confusing but it definitively works.
Basically the end result you should get is this:
Autologin with AnonymousUser when you enter the pentaho URL
AnonymousUser only has read privileges
In case you want to edit you enter the login URL and use admin credentials