The instructions on the JanRain installation page says to load the app id dynamically. Could someone explain what that means? This is Javascript, so the appid has to go the client, correct? Thanks.
http://documentation.janrain.com/engage/widgets/sign-in
Yes - as the documentation states, you need to provide your AppID (provided on the home page of your Janrain account). Depending on what your choice of server-side markup is, you can provide the AppID as a server side markup sequence referring to a configuration source, or something similar.
This is a suggestion made so that if you need to change this key at some point (perhaps the application gets compromised and you need to change your app and secret keys, you change your application name) there's a single location in some configuration file to change instead of throughout all your web pages.
Without any further knowledge of what your server side technology is, I can't be more specific about how to implement the "app ID dynamically (through configuration)".
If you're confused about having multiple keys, think of it in the way of public/private key authentication. The App ID is your public key; with which you communicate to their the servers publically to say who you are (along with the URL used in the RPX widget, which also identifies you and your application).
When you receive your callback through the token url provided to them, you make the call back to them server side and use the private key there (as well as communicating via SSL), to complete the authentication.
Related
first of all before this gets marked as duplicate with CORS and X-header comments, let me prefice this by saying.. This question is strictly intended for LOCAL environments only.
I have written a website with .NET as backend that uses cookies and session-strings to maintain the authentication between the client and the website. However, a customer of ours want to disable authentication all together for all their users. Here is where the problem arises, our system rely on the fact that usernames and auth-data is sent along in most of our data-requests. So, the customer has agreed to use a static page with the username and password statically programmed (so that they wont have to login every time, but mearly open a chrome/firefox-shortcut on their desktop). This static page will redirect and pass along this static information to the "real" loginpage and sign in the user.
Illustration:
What are my options here?
Here's a screenshot of the req-headers in a successful login-post.
Thanks.
You want to serve your site from the backend and distribute a link to your site. Your client then bookmarks the link (or pins it to their home screen).
Serving static HTML files has fundamental limitations and you will hit a brick wall sooner or later (e.g. AJAX calls require the site to be served from some domain).
From here, there are a couple of options to do what you want.
The orthodox route is to delegate credential storage to the underlying OS. That is, just program the input forms as usual, issue Cookies as usual, and make sure the form HTML is such that the browser offers to save the credentials.
An alternative solution more in the vein of your initial proposal is to create what are known as signed URLs. You may create cryptographically signed URLs (e.g., http://localhost/your/site?hmac=<your_signature>) and hand that your client. Once you handle that URL in your server and verify the signature is valid, you may respond with a 301 redirect to your site, issuing the authentication cookie in the redirect response.
For background material, you may want to read about Post/Redirect/Get and Message authentication codes.
Good evening, I developed a system that behaves in the SaaS format, where the client only registers and already has access to use, in it I used a unique identifier for each client and they all use the same structure, PHP files and the same database . So far so good, because the domain does not change, that is, everyone uses www.lalalaetc.com.br/app and the system separates everything by the unique identifier, however, I would like to develop a virtual store from it, only there would be a difference, the domain, that is, I believe the principle is the same, use a unique identifier for each store, but my doubt is how I will make it so that when someone accesses the store the domain is addressed correctly and load the id of my client? What is the way forward and what do I need to research to do such a feat?
It sounds like you want to develop a multi-tenant application.
In this case, you could uses sub-domains, for example tenant.lalalaetc.com.br.app, where the word tenant is replaced with a string unique to each tenant.
When the request comes into the server, you can parse out the sub-domain, passing it to a function that searches your API/Database by this tenant subdomain.
i managed to handle the tenant with the folomming steps:
i cloned de the parse server source and i added a new middleware named "tenantConfig"
in that middleware i intercepts the requests and i get one specific header that i named "x-parse-tenant" and i use the value of that header like a database name
so i modify the datapase adapter and then resent it to the requetes and do next() to continue the process
so in the client lib or the requests i provide a "x-parse-tenant" header
you can see details in the screenshots
its not perfect i know :D
I am developing a web application using Facelets and Entity-Controller-EJB structure. In the application, there are contents which are reachable only if you are logged. A bean checks the login state every time you click on a button/link for the restricted contents, and redirects you either to the selected page or to the login page.
I thought that this way is not safe, as you can write the link directly in the browser instead of generating it from a button that checks the bean. So what should I do? Is there a render option embeddable in each page or should I write a javascript function? In this case, what should I do? I have studied js fundamentals but don't really know how to implement this control!
Thank you for reading!
You cannot rely only on frontend to deny access to some parts of a web application.
This because all the HTML/CSS/Javascript is downloaded on users' browser, so they can read your code and your authentication mechanism, and understand how to bypass it (or just disable it).
More on this: Why are browsers allowed to display client-side source code?
What you need is implementing some security mechanism in the backed.
The simplest one is to delegate this to your webserver (here the instructions for Apache) and then use something similar to this to do login.
Another way is to have a proper backend: you send data to it (email/password) and it provides you a token that you use to access protected resources.
Or also, dinamically create your documents on server side, only if the user is authenticated.
I'm setting up parse framework in javascript. I notice that I need to call
Parse.initialize("app", "secret")
Since this is in the page source, couldn't anyone take this and make calls against my account?
Is there a more secure way to store this info?
As per Parse Security Guide your JavaScript key is NOT secret:
When an app first connects to Parse, it identifies itself with an Application ID and a Client key (or REST Key, or .NET Key, or JavaScript Key, depending on which platform you're using). These are not secret and by themselves they do not secure an app. These keys are shipped as a part of your app, and anyone can decompile your app or proxy network traffic from their device to find your client key. This exploit is even easier with JavaScript — one can simply "view source" in the browser and immediately find your client key.
So yes, anyone who found your key can make calls.
But you can (and should) restrict what such anyone can do.
Using Class-Level Permissions you restrict what can be done with individual classes.
Using Object-Level Permissions you restrict what can be done with selected objects.
See also Roles and Roles Hierarchy for simultaneously setting permissions for a group of several users.
For instance, you can restrict access to only specific users. Only if one of those users is logged in, the access is granted. Any other "hacker" can try to use your keys but the request will be rejected by Parse.
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.