I am developing a CMS. One of the greatest everyday annoyances when working with it is that when you are on a front-end page, not logged in, and want to make a change, you need to go to the back-end login first, log in, and then navigate to the page you want to change.
I would like to introduce a smart little function that pops up a log-in screen when you hit a certain key combination. I have already set this up with double Ctrl. I have come to realize, though, that I hit that key so frequently that the login pops up unwanted, something that must not happen of course.
So, I am asking for your ideas for a clever key combination.
I am looking for a key combination that is:
Elegant and easy to memorize (this is why I liked double Ctrl very much)
Time considerations (Press key X, then Y after 1 second) are possible
Must not be mapped to any browser function of course. I realize this cannot be excluded 100% but obviously, Ctrl+A or Alt+Tab would be nonstarters.
Works on all keyboards (Mac included, but I'm willing to handle the apple special keys)
Extremely unlikely to be hit accidentally
Other clever ideas like simple mouse gestures are also welcome.
It can be argued that this poses a decrease in security, as the URL to the back-end login is made available in front-end pages and loses the additional protection by being obscure. I may address that later using a cookie that identifies CMS users' machines but it is not the issue right now.
Oh you just KNOW you have to go for the Konami Code!
There are several websites that implement it - take a look at this list.
I know it's not the simplest, but it does have the geek factor ;)
Why not just have a "Editor Login" link at the bottom of the page?
It won't be any less secure and will be a lot easier to use. I can see the solution you are trying to use causing all kinds of odd problems down the road...
If you really really want it "hidden", you can just make it white text on a white background or something.
What about the simple ` key at the top left corner of your keyboard? This is often used in games to get into a console mode (counter strike, left 4 dead, etc). It is mac/windows/linux compatible and shouldn't interfere with anything in the browser.
Related
First of all I apologies if am not aware of similar questions been answered, if so please enlighten me so I can refer and learn (In case they satisfy context of my problem).
So, context is my question is completely based on Autoplay Policy Changes. Right now this policy imposed to take down unwanted stuff or advertisements to be auto played without user's consent. Possibly causing security threats and bandwidth consumption specially on mobile devices.
The only solution to make it work for some legitimate use is to make user interact with website. That's cool, I tried to accomplish this by showing an 'alert' box, but it is not satisfying that criteria (Make user interact first). Rather if I add a button to the document body and click on it, then the criteria match I can listen the audio I want to play on page load.
So I wonder whether these boxes are alien to DOM ? or do they belongs to client only?
I appreciate in advance for any solution which could have been obvious, pro, immature or lay man's knowledge for me to realize. I am a learner.
As JavaScript is Client-Side, the popup boxes are part of the browser (= environment). That is why the alert() function's complete name is window.alert(). They are not part of the DOM.
I was wondering if there are any methods to check if a website is successfully displayed or rendered on the a user's system.
The application of this is to to deliver a content if and only if it is a real user rather than a crawler/spider fetching the content.
so the check would be:
-check if the content is rendered/displayed,
-execute the next script
-otherwise
-do something else
any help is highly appreciated.
Cheers
Most crawlers simply do not execute any JavaScript, but you cannot really rely on that since it's easy to imagine a sophisticated company creating a search engine that actually does mimic a JS-enabled browser. Many crawlers have an easily identifiable user-agent string, but you cannot rely on that either.
You could do something, I suppose, like attempt to poll for the mouse x,y position a couple of times, looking for values other than 0,0, which is likely to indicate a person with an actual computer and pointing device is at the other end. That still may not get what you want for touch screen devices though. You might also consider waiting until you detect a scrolling event if your secondary scripts don't need to load right away.
We are currently building an advanced JS/AJAX-based service, and allowing the back-button to function in a meaningful way is obviously important. I've looked around some, and been in-contact with iframe-hash/anchor-solutions before, but the ones I've seen and found are all based on the idea of going back/forwards in a page structure. What I'm looking for is to find a way to bind the back-button to act as an alternative for "close" / "cancel".
The solution to what I'm looking for is simple, to almost always keep exactly one additional back-history entry (except for when "we" decide the user is at the "start"), without showing a hash-tag in the location bar.
I did have a try at implementing it myself, a hidden iframe for which I change the hash, worked well, in all browsers but IE, it refused to update the hash-tag for me when pressing back. Are there any solutions out there that solve this problem (trap back-button, no visible hash-tag)? Or any simple cross-browser solutions for dealing with hidden iframe hashtags?
Sorry for the partial answer, but this looks promising: http://code.google.com/p/reallysimplehistory/
I'd like to keep informed of your progress on this, it's a useful thing if it's practical to implement.
Dan
I got a problem with a website that use onClick event to add items to the cart. The problem comes up to visually impaired users that cant use keybord to add the products.
I guess that bringin back the add function with a normal href="addtocard.php?id=1234" should solve the problem but on the SEO side this can effect other problems.
Is there any other way, maybe using events such as onkeypress, or that's totally related to the use of javascript? Thanks in advance.
Having an addtoCart.php?ID=5 should not have a detrimental impact on your SEO. Modern/top search engines will be smart enough to recognise what the function of that page is, and index it accordingly.
When designing sites, I forget the specific name of this type of design, but it is always best to build it upwards, that is add on the onclick/javascript functionality as an extra over the top of the base of your site, so that if users have any of these features disabled the site will still function perfectly, so that is something to consider when building your next site.
So I would recommend building the addtoCartPage. I don't think it's as bad as you think it is.
You can use something like this
Add To Cart
Or somethinkg like this
Add To Cart
It's the other way around from what your SEO consultant said. Most visually impaired people prefer keyboards. It's mice they can't use so well. The name makes you think that onclick only works with a mouse, but in general, onclick works fine for the visually impaired/non-mouse users, since it is triggered with the Enter key as well as with a mouse click. See http://webaim.org/techniques/javascript/eventhandlers#onclick.
That's why using onkeypress for accessibility is not a good idea. Jeremy Keith flatly says, "Beware of onkeypress" since even a Tab key could make it fire.
Besides progressive enhancement in general, you might try Unobtrusive Javascript in particular, which uses Javascript to rewrite links, and that means users without Javascript get regular HTML links. If Google can't follow your Javascript links, you do have an SEO problem.
I want to prevent users from printing a page
I thought I would set the screen to not include the toolbars, and prevent right clicks, and prevent Ctrl+ P, and the Print Screen button.
Can this be done?
Is there any good code out there for this? I have searched quite a bit so far, but not much luck. I know this isn't foolproof, but it will prevent some users from copying or printing.
You can't do this...you can't disable the user's ability to print, nor should you try.
Ctrl+P is the way a programmer prints, File > Print (depending on browser) is the way the typical user does...so this wouldn't even disable the most common method. In addition, any decent programmer can get around this anyway, so it effectively doesn't stop anyone.
Any data you get to a user, displayed or not, they can see, copy, print, etc...there's nothing you can do to prevent this, definitely not 100%. If this is one of your requirements...you should be asking if a website is the best way to deliver this data.
By doing that, you will annoy legitimate users, and if you think a serious copyright violator uses a regular browser (whose printing function you can disable), then you're very mistaken.
On the one hand information wants to be expensive, because it's so valuable. The right information in the right place just changes your life. On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower all the time. So you have these two fighting against each other. source
Also:
Information Wants To Be Free, and Code Wants To Be Wrong.
I agree with the answers above.
Users will always find a way around this,
- A computer is not secure for copyrighted material and will never be.
you need to take that into account.
If you'd want to make it so that regular computer users can't do it this would help:
Create an application that loads and displays the document after input of a keycode that you supply (check via webserver).
the application does not have printing functions since you did not put them in
register a global keyhook to blank the document if the user presses "printscreen" and show a copyright warning
A couple of years ago, I built an exam system where one of the requirements was to make it hard for people to print the exams. Removing the print functionality is as we know, impossible (unless you do some changes in the browser software). What you can do is to make it harder for non-technical people to print the page. E.g. Use CSS to blank the page when it goes to the printer:
<style type="text/css">
#media print {
body { display:none }
}
</style>
The following jQuery script will prevent copy&paste in some browsers:
$(document).ready(function () {
$(document).bind('copy paste', function (e) {
e.preventDefault();
});
});
the #Nick Craver answer is right, you can't prevent it but anyways if you want to detect the key combination using mootools you have the keyboard class that let you define key combinations and add events to it:
http://mootools.net/docs/more/Interface/Keyboard
that maybe will be useful to display a warning or something like that :)
You could so with jQuery for example. However think of this: a browser runs on a client pc which is owned by someone. That person should be in control of what happens on his/her device. It's not up to you to start putting scripts to get rid of standard functionality the enduser might want to use.
If you don't want something to be printed then don't show it on a public place. If it's confidential, treat it as such.
Grz, Kris.
Take this into account. I agree with the other answers and present another way around this. All the user must do is take a screenshot, which involves the application layer of the operating system, and one of which you cannot even hope to change. On Ubuntu, it's even in the user's main menu to do this.
<script type="text/javascript">
function detectspecialkeys(e){
var evtobj=window.event? event : e
if (evtobj.altKey)
alert("you pressed 'Ctrl'");
evtobj.preventDefault();
}
document.onkeypress=detectspecialkeys
</script>