I'm looking to securely lock content on a basic html site based on various permissions of the user. I'm looking to have a pop-up modal appear when the user's permissions don't check out... however it seems to be that any savvy user could simply open the console and delete that element (thus revealing the page anyways).
What am I missing here? What's the best way to approach this so that no matter what the actual page can't be accessed?
Thanks in advance for the help!
If content is downloaded to the client, it's always technically possible for a savvy user to access it.
You can either live with that, or alternatively do something like the following:
Load the basic page template without any content
Use an API call using cookies/other auth to get the content
If logged in, display the content, if not, launch the modal.
Ok here is my answer to this one.
The answer given was agood one, you can't hide the content truly so your options are:
Don't download all the stuff you want until you have auth'd the user (via cookies etc.
Use a simple redirect/buffer page infront of your hidden content.
In my use case (shopify) partial downloading of store content isn't exactly configurable (or i don't have enough knowledge of their template language + theme design to pull it off!), so I made use of javascript and cookies in order to check a user's status. If the user didn't pass they'd get kicked back to a landing page. Good enough!
Related
I hope to explain what I need in a clear way.
I have a site (which uses Javascript and Jquery) which should be accessed only by customers who are in good standing with payments, and I recognize them reading a server side database.
The mechanism works pretty well, but there is a minor problem which should be addressed.
After the validation check, if further site access must be blocked I use the following brutal code to show a message in a DIV (id=noway) and then stop any operation:
$("#noway").html("<p>You are not allowed to proceed since your payments are overdue</p>");
while 1{}
Problem: the DIV does not show anything until the browser's (mozilla) timeouts with a 'script in the page has stopped...continue..exit...' message.
It seems that Mozilla enters the infinite loop before of completing the DIV update. What can I do?
Besides this, is there any other more elegant way to block any further visitor activity?
Actually I thought to redirect the visitor to a different page with just the advice, but I would prefer not to do in this way, if possible.
Thanks
I think the best way to restrict site access is to do it server-side. Your page shell read the server-side database before it build any client-side output. So, if the user is not authorized, than the only page content shell be the message about the payment. And only if the user is OK, then the page outputs all the regular contents.
$.ajax({url:"URL",success:function(result){
I have a webpage that accesses a certain URL and then extract certain elements of the webpage. However, in order to access that URL you have to be redirected to what is similar to a log in page (requires form submission) and then you have access to that link.
I want to prevent the redirection upon loading the URL. Is that possible?
If not, am I able to manually do the form submission using JAVASCRIPT? Via AJAX or any other resource.
EDIT: By manually saving the .html to my directory and accessing the page from my root folder, it works fluently.
Thank you!
Yes, it is possible. You need to stop the form submission and add your AJAX call. Like this:
$("form").submit(function(){
$.ajax({url:"URL",
success:function(result){
}
});
return false;
});
More information here.
If I understand your question, what you need to do is log the user into the external website programmatically beforehand. This is possible if the other site supports OAuth or something similar, but the specifics will depend on their API and what exactly you're trying to do. I can't tell you more than that without more information.
This assumes you're trying to include the other web page in an iFrame, or link directly to a page there, or something like that. If, on the other hand, you're trying to log in to the foreign website as the user, pull out some content, and mix it in with your own, then I suggest you change your approach. You'll probably run afoul of all kinds of anti-XSS security policies, either on the foreign website or in the browser depending on what you try to do. Or you'll have to ask your users to give you their password on another site, and they'll have to really trust you for that.
Generally speaking, if you want to interact with another website, the user's client should connect, log in, and receive content directly from the other server without you acting as an intermediary. I think perhaps you're asking the wrong question: Instead of "how can I do this without the user logging in," ask "how can I let the user connect and log in to another website without having to leave my page?"
I have a client web application that allow users to LOCK the screen without the need to log out from the application, this action just hides the elements on the screen and show a lock screen.
Obviously, when I inspecting the elements on the page I still can see the elements on the page and their data.
What is the best solution to hide the elements from the inspect html? storing the html on javascript parameters and removing the html from the page will be a good solution for this problem? I'm just thinking of it and it seem that their is not a secured solution to hide data in html
If your lock is for security reasons then it's better to implement a server-side lock and move the user to another page (saving the page state and restoring it afterwards). Messing with the markup using JS is more complicated and everyone can fool your logic by disabling or executing some inline JS with a debug tool.
The only option is get html content, store it in, say, localStorage encrypting it with password, which user should input and don't save that password. Then when user returns, prompt for password again and decrypt content.
Server-side solution with logout/login should be simpler, though.
Anyway, you'll need to identify user in order to protect your app from unauthorized usage of another person.
I'm going to be creating a widget style tool that will work as follows:
It can be included in any page by putting a script/button combo on that page.
The button, when clicked, will load a form from my site, which can be filled out and submitted.
Depending on the submitted information, there may be another form displayed - for example, a second page with a captcha, or a confirmation page with some action required, or maybe just have the form close, or some other action I add later.
If I was to open a popup window, this would be easy, just build it as a regular page. However, including this in a calling page, presents a few issues.
If I actually load the form content into a local div on the calling page, it becomes part of the page content. I know I can manipulate that content to some extent using the script (it will load a script from my site for that particular version of the widget), repost forms and load them into the same div, hide the div when I'm done with it, etc. But it seems like it would complicate things.
My other option is to make it all happen in an iframe, so it's not really part of the loading page calling page. This way I sort of feel like I'm losing some functionality I may need later. This is probably the way I will go anyway.
However, before I start down that road, I thought I would ask if anyone has any tips on the best way to include a complex series of pages in another page?
Whatever I do, I want to be sure I don't close doors on my ability to change the way the widget functions, I will definitely be adding functionality later - so keeping my options open for change is important.
Thanks!
Edit
Regarding JotaBe's question, on the server side, I will be using PHP.
However, I'm pretty sure that doesn't matter, as the PHP processing will (as always) happen on the server. All the client (requesting page), will know is that it requested, and then received JS/HTML/CSS/JSON/ETC assets via HTTP. It won't know, or care, how the server generated those resources.
If it helps you to picture it though, this is the basic idea of how the client and server will (if I don't think of a better way) work together:
The client page will (at load) request a .js file from my site. This file will be generated dynamically based on the requested URL. For example, account #74 would request http://mysite.com/widget/js/74.js and receive JavaScript assets customized for that account.
When the "widget button" is clicked, it will use the JavaScript to request an HTML form from my site, and include it in the page, one way or another (which way is best is the whole question). The HTML form will be generated dynamically and customized for account # 74 based on the request (ie: http://mysite.com/widget/form/74.php).
Once filled by the user, the form will be submitted to my site. The post will be processed and stuff will happen, again based on the requesting account (ie: action=http://mysite.com/widget/post/74.php). At this point, I may need to reject the form and request a re-post for failed validation, captcha verification, etc., or I may need to serve a confirmation page, or simply close the form, or some other action.
Any way you do this (language / platform / etc), the best practice is to use mvc, or hmvc, to keep the various logical components of the application separate. You can create popups by having some view templates which don't render their containing tags, designed for javascript / jquery .load() statements. You could then design a series of components designed to be loaded with arguments passed over the uri.
here is an article that might help explain one possible design pattern for what you are going for:
http://www.phpied.com/ajax-mvc/
I am writing a Facebook application that is a simple board game which I have implemented in javascript. Facebook only seems to let javascript applications run within an iframe so I am loading the page using <fb:iframe>. I just want to be able to tell the javascript the user's id so I can tell the user if it is his turn or not but I can not find documentation on accessing facebook data from within the fb:iframe. I am probably missing some basic conecpt as I do not understand the facebook API very well.
Facebook's API is very tough to follow, and the documentation is very poor. You're right about the Javascript... normal Javascript only works inside an iframe on Facebook, otherwise you're limited to a subset of filtered Javascript called FBJS. You can safely ignore anything about FBJS in the documentation, and focus on iframes.
Iframe loading
The first thing I would mention is that an <fb:iframe> tag actually gets rendered with a ton of stuff in the src attribute. So if you put a tag like this into your Facebook page: <fb:iframe src="http://example.com/page?x=y">, what it ends up becoming when it loads into a user's browser is more like this:
<iframe src="http://example.com/page?x=y&fb_sig_in_iframe=1&fb_sig_locale=en_US&fb_sig_in_new_facebook=1&fb_sig_time=1246340245.3338&fb_sig_added=1&fb_sig_profile_update_time=1242155811&fb_sig_expires=1246345200&fb_sig_user=000000001&fb_sig_session_key=2.d13uVGvWVL4hVAXELgxkZw__.3600.1246345200-000000001&fb_sig_ss=mZtFjaexyuyQdGnUz1zhYTA__&fb_sig_api_key=46899e6f07cef023b7fda4fg2e21bc58&fb_sig_app_id=22209322289&fb_sig=bbc165ebc699b12345678960fd043033">
Facebook adds a ton of stuff to the src. The parameter that tells you the user's Facebook id is fb_sig_user (which is 000000001 here). I'm assuming your app is set up as an "FBML app", since you probably wouldn't use an <fb:iframe> tag in an "Iframe app". Nonetheless, the rendering method is similar in both cases, and you get a bunch of extra stuff to your src document in an "Iframe app" as well.
This really only passes you the Facebook user id on the first load of the iframe, however. Subsequent operations within the iframe won't have access to that user id unless you pass it around explicitly.
Facebook Connect
If you want to interact with Facebook from within the iframe, that's where the Facebook Connect Javascript libraries comes in. The best instructions on setting up Facebook Connect is probably this wiki page, but it's still a bit murky. Facebook Connect can be used for both completely external sites, or just regular content inside an iframe. You fall into the latter category, so if you follow the instructions in that link and use the first line of code in step 2 (for the FeatureLoader), you should be ok.
Once you've included the FeatureLoader.js script and called FB.init, you should generally be up and running with FB Connect. You should be able to interact with the API from then on out. The users.getLoggedInUser() method will give you the current user id inside the iframe via Javascript.
Hope that helps.
Note that as of March 2011, FB is moving to POST requests to load iframes. It sends a form action with method="post" and target="iframe_canvas", plus an input type="hidden" with a "signed_request"
You cna use the facebook API to get the user ID by calling
Users.getLoggedInUser
You can access that value, then use echo() to add that to your HTML as a javascript variable, which will make it available to your Javascript code.
Try Env.user, it has the logged in user's ID.