I have an existing website which is built using express and node.js , I have to incorporate nodebb forum in that website which is again a different node application, I am using facebook login for both of them but I have to login into them seperately one by one(using same facebook app for both). What I want to do is,
1.Login via fb or any sso in the main site and the user should be logged in the forum via the same automatically.
2.How can I integrate nodebb in my website so that the look and feel doesn't change, it looks like I am on a completely different website, just need some tips to integrate nodebb in my existing website.
How can I achieve these two?
(Hey there #Vipul, NodeBB dev here) When you establish the express session your app, what are you setting the cookie's domain to?
;domain=domain (e.g., 'example.com', '.example.com' (includes all subdomains), 'subdomain.example.com') If not specified, defaults to the host portion of the current document location.
-- MDN
You'll probably want to set it to .your-domain.com, and likewise for NodeBB (do it in the "Settings/Advanced" section):
Then also make sure the key in your app is set to express.sid, which is the value we use, and that the secrets match.
Related
We have a chat interface that we allow our partners to embed into their websites and web apps using a JS snippet. We want to expand to integrating with native apps using WebViews.
I am seeking an approach to verify that our snippet is only running in specific apps.
As an example: A similar functionality that is easily achieved in web apps is a domain check.
A partner / client gets a JS snippet or a URL and a key,
on page load it looks up the partner details using the key,
if they're active and approved for this service,
check the requesting domain against a list of whitelisted domains for this key.
Is it possible to uniquely identify a native app from a JavaScript function that is running in a WebView to verify the app? Perhaps - are app store unique app IDs accessible from within a WebView?
Thank you
No, it is not possible to uniquely identify a native app from a JavaScript function that is running in a WebView.
"No" is a hard answer to find on the web. Phone a friend informed me that while some native information and functionality is accessible from within WebViews, the app ID or bundle identifier is not exposed programmatically. Of course a developer could add it, but that's not helpful in verification.
I don't have any idea how to implement this. After a bit of search I found out that medium keeps track of the browser and not the user, what is mean is you can access three free articles from each new browser on the same machine (if I am wrong do point it out). I am using React and Firebase for my website.
Edit: I was thinking along the lines of getting some kind of id which is unique to a browser. As cookies and local storage can always be bypassed.
I don't know if it's a clean way to do it but you can associate an IP to an unique counter. Or with a cookie but he can bypass that by cleaning the cookies
The answer would tightly depend on your application setup and especially on the service backing your front store.
If you are using a self-backed backend, for example a nodejs - express based server, within your route middleware you can access the remote address from the req.connection.remoteAddress request property along with the user-agent req.header('User-Agent') and forward these to your datastore being Firebase in this case.
If you are deploying your application to Google Cloud Function, you can then access the remote peer address using the fastly-client-ip request header and still forward this to your storage system.
Use javascript and implement a system that uses a cookie or local-storage to verify how many articles are read on your website.
On most of these websites however you are still able to bypass this limit by clearing the cache or using a incognito window.
To also limit these scenarios you can use a cookie in combination with an IP address, which has its own drawbacks, especially in corporate environments, and mobile connections where IP addresses are heavily shared or changed. Depending on your situation this may matter or not.
I have a challenge that I can't solve. I have made a website with node.js and have all of the code written for the routing including routing for sub-domains. Some location only some users can access, some locations only logged in users can access. I wanted to include a chat for my users so I went along and created one with socket.io and some client side js.
Now I need the site to keep the chat element open which in on a bar across the screen when the client goes to another portion of the website. I have looked into many solutions but almost all of them include some js library like angular.js with the ng-model or ui technique but all include writing code for the client side that handles the url and what to load.
I don't really want to do this method because:
I don't want to re-write all my routes and I am not even sure how to handle the authentication of the users.
I find the client method to be a security issue
My website isn't a single page app, I just want one portion of the website to stay loaded.
Here is some images of what I am wanting:
State 1:
State1
State 2:
State2
Notice that the chat stays but other content was loaded. Also that it went to a different sub domain and a location that is only accessible by logged in users.
Thanks!
I guess you want to maintain state across page refresh, much like e.g. Facebook does. A true and trusted way of doing this is setting a cookie that stores the chat state: open/closed, or store the state on the server. Then on page load, initialize the chat based on this data.
I want to create a web widget that will display information from my site.
The widget will be included in the client's website HTML using JavaScript, and should only be usable for my clients -- web sites that were registered at my site.
The information in the widget should be specific to the user who is currently visiting the client's site.
So, I need to authenticate both the client (website owner) and the resource owner (website visitor). This seems to map nicely to OAuth 2.0, but I couldn't find a complete example or explanation for such an implementation.
Any resources or pointers to such information will be appreciated.
Update: I've stumbled upon this article, which provides an outline for an approach that uses OAuth. However, it is not detailed enough for me to really understand how to use this with OAuth 2.
There are many large organizations that have done this, and I'm sad to see no other answers for this question since it's such an important web pattern.
I'm going to presume that you are not rolling your own OAuth 2.0 provider from scratch, if you are - well done otherwise you should be using something kickass like Doorkeeper to do this for you.
Now, in OAuth 2.0 you have the following entities:
Users registered on your website
Applications registered on your website (who subscribe to your oauth2)
User Permissions which is a list of Applications that a user has 'allowed'
Developer (who is consuming your auth API / widgets and building an Application)
The first thing to note is you must have a domain name associated with each Application. So if a developer registers for a API token / secret on your website, the Application he creates is mapped to a unique domain.
Now, I presume that the flow for an application to authenticate users via your website is already clear. That being said, you don't need to do much for this to work.
When an Application sends the user to your website (in order to sign in) you place a session cookie on the user's computer. Lets call this "Cookie-X".
Now the user is authenticated by your website and goes back to the Application. There we want to show a custom widget with information pertaining to that user.
The developer will be need to copy paste some code into this app.
The flow is like this:
The code will contain a url to your website with his Application ID (not secret) which he got when registering his application on your website.
When that code runs, it will ping your website with his appId. You need to check that AppID with your database, and additionally check that the referrer url is from the same domain as that which is registered in your website for that AppID. Edit: Alternatively or additionally, the code can check for document.domain and include it in the ping to your website, allowing you to verify that the request has come from the domain that has registered with the given AppID.
If that is correct, you reply back with some JS code.
Your JS code looks for the session cookie your website had set when the user had signed in. If that cookie is found, it pings back to your website with the session and your website responds with the custom view content.
Edit: as rightfully mentioned in a comment, the cookie should be HttpOnly to safeguard against common XSS attacks.
Additional Notes
The reasons this is a secure approach:
The AppId and domain name are a good enough combination to verify that other people are not fetching this information. Even thou the appId is visible in the applications html source, the domain name would have to be spoofed by anyone attempting to use someone else's AppID.
Presuming someone takes an AppID which is not his, and writes code to spoof the domain name of the referrer when requesting for your widget, he still won't be able to see any information. Since you are showing user specific information, the widget will only render if your website can find the session cookie it placed on the users browser which can't really be spoofed. There are ways around like session-hijacking, etc. But I think that's beyond the scope of this question.
Other Methods
Just by looking at Facebook's Social Plugins, you can tell that there are other options.
For example, one might be to use an Iframe. If you ask the developer to add an Iframe to his application, you can even reduce a few of the steps mentioned above. But you will have to add JS along with it (outside the iframe) to grab the correct domain, etc. And ofcourse from an accessibility and interface standpoint I'm not very found of Iframes.
I have an HTML5 app which is capable of running offline. However, I need to password protect the directory this app resides in to only allow access to authorized users. Initially I was using a PHP login page which set a cookie (outside of the app directory) then redirected to the app directory. The app (JavaScript) checks for the cookie and if it's there it lets the user run the app. If not, it redirects them back out of the app directory.
The problem with this method is that all of the files in the directory are still accessible if referenced directly (which I don't want). I do not want users to have to authenticate every time they hit the directory (it's a one-time authentication process; the cookie is there so that they never have to type their username/password again), and I also want to have a stylized login form (i.e. not using the default browser login box for http authentication).
Finally, because this is an offline HTML5 app, I can't include any PHP code in the app itself.
Any suggestions?
That doesn't sound like something you could do from Javascript. The script would need access to the file system to be able to restrict access to the folder, wouldn't it?
Unless this feature is exposed by the browser via a javascript API, I don't think it will be possible. It sounds like it would be a useful feature though.
Perhaps you could encrypt vital data, but apart from slowing down the application, I'm not sure what good it would do, since all the necessary keys would have to be stored locally as well...
Since the general rule of security on the web is that you can never ever rely on anything that happens client-side (e.g. in Javascript) without a double check on the server-side, this will of course pose a problem when the app is running offline and the server-side is not available :(
Looking at the "make Javascript redirect if the cookie exists" problem, unless I'm mistaken, it would be trivial for a malicious user to edit the Javascript, using for example Firebug, to redirect in any case.
EDIT: By the way, what level of security are you looking for? The "mom won't be able to accidentally access my account"-level (which it sounds like you already achieved), or the "no one, except maybe the NSA, should be able to hack it"-level?