I'm building a web based app that works with QR codes. Is there any way to know that when a user lands on a URL that the user came directly from a scanned QR code? Instead of going directly to the URL? I don't want the user to be able to go back to that same URL a few days later and refresh a couple of times without doing new scans. I realise this is a long shot and I know building a custom QR scanning app might be the only way but just seeing if anyone has any ideas?
I suppose that you could add a value to the url's query string indicating it is from a QR link, e.g.
http://myserver/mypage.php?QR=1
You would have the page automatically redirect (meta refresh, whatever) to:
http://myserver/mypage.php
But by this time, you would have associated this session with a QR code being used. Hopefully, the user won't have noticed this sleight of hand, and would be left with the browser only showing the second URL. Only if the user went back to the QR scanning app would s/he realise what would have happened.
No there's no way to do this in a seriously secure way. I suppose you could create a custom application that scans, then performs some secure logic that the user can't tamper with. Aside from that, any mechanism that relies on the browser to open URL X can be triggered by the user just entering X. There's no difference from your server-side perspective.
Related
So I'm building out an app with Meteor and noticed when I log in with Twitter and then Facebook, I create two separate user accounts. Is there any built in way to make sure these are merged? I'm not seeing any email address in the twitter based user account, so I can see it might be difficult to figure out which accounts to link.
Suggestions? Thanks!
I've been in a similar situation so here's a good starting point for you:
You might want to do the merge at the Accounts.onCreateUser event. Basically, what you would do at this time is to:
Do a mandatory protocol / routine to save the email in some profile field in any authentication method as much as possible, so that you are able to do the next step, which is..
Whenever another authentication method is used (to create the user), you can compare the existing database of users (now confident that an email field would be present at all times to check against), and do the merge whenever an exact email match happens.
It's a shame I do not have the code now because I tried this protocol once, but I quickly decided that I'll just stick with one authentication method for some reason. Maybe I'll update this answer when I can get around to try and code that again.. or maybe not.
How to restrict the page by accessing only one user at a time. Using asp.net can i use global.asax, is there any other way to restrict, if one user accessing the page, another user not able to access that page. we have to give message that one user is accessing the page. is it possible. can you help me or give some reference.
Although there are probably many better ways of dealing with this sort of problem, I'm going to assume that you do actually need this.
What I would do:
Make your application so that when the page is loaded(when it isn't "locked"), it logs to a database that the page was loaded and "lock" it. In the actual page, I'd have some kind of AJAX to constantly poll the web server every 5-15 seconds to tell your application the user is still on the page. And then make it so that the page becomes unlocked after 5-15 seconds from the time saved to the database by the last AJAX call.
Again, I really suspect that there is a better way around an issue like this, but this is a direct answer to your question
Based on this:
yeah sure, jupaol, it is depend on accounts, in my web application, one report has to approve only one user, but the approve authority having two users. if both of them accessing the same page and approve at a time, it will big mess. here i an not using database.
The problem is related with concurrency, there are several ways to face an issue like this, for example the easiest one is to use optimistic concurrency. Even when you are not using a database for this, you can emulate it.
You should be storing the result of the approvers somewhere, in order to mark the report as approved, with this in mind you should be able to do something like this:
Before render the page get the latest report status
If the report has not been approved, render normally
If the report was approved seconds before, render it in read-only mode reporting who approved it (or similar approach)
Add a validation to your ChangeStatus method, in this method do the following:
Get the latest status of the current report
If the report is still not validated, then block the thread (you could use a Mutex or similar) and mark the report as validate it
If the report was already validate it, raise a domain exception and handle it in your page correctly (perhaps render the page in read-only mode explaining that the report was already validate it)
If you want a more responsive application, (RIA), you might want to consider the following approaches:
Perhaps this would be the worst approach but it's still an option, you could keep a log tracking when a user request your page, then in subsequent requests check if the log is still valid, if it is not, then redirect to another page indicating the page is in use, otherwise allow access to the page. I believe this is an error-prone approach because you would be relying on this simple validation in order to prevent an inconsistency in your system, besides you would have the polling problem described in the following approach
Using AJAX to poll data from a service checking if the report has been approved. Perhaps this is the easiest way to accomplish this but it is not recommended it, because you would be polling your server constantly, and eventually you would have scalability problems
You could use Comet to get notified to the browser (client) whenever a server event has occurred, in this case when your report has been approved. The problem with this approach is that you have to keep an opened connection with the server in order to get notified.
The last approach and the most recommended these days is to use Web Sockets, this is the technology used in StackOverflow to get notifications in real time.
Here's the question scenario:
Suppose you have a multiple-page ASP.NET web site with the following
requirements:
User-specific data for the currently logged in user is loaded and is required on each individual page of the application during a user's session.
The application itself only allows a certain number of users to be logged in at one time.
The next time a specific user logs in, the user should be returned to the last page visited.
Given this information, briefly describe how you would use ASP.NET to manage the state of the application to meet these needs?
Here's my thoughts and reasons. Please provide yours.
User-specific data for the currently
logged in user is loaded and is
required on each individual page of
the application during a user's
session.
This is suggesting to me that the interviewer is looking to see if I would suggest using Master pages as a way to provide a common approach to displaying the same thing on every page.
The application itself only allows a
certain number of users to be logged
in at one time.
Could the sought response be that, because scaling isn't an issue due to the limited number of users, that it is OK to put this information in the Session object for performance reasons or is this a trap and some of approach is better?
The next time a specific user logs in,
the user should be returned to the
last page visited
A cookie seems the best approach to track the last page access, since this doesn't seem to be critical information.
Please tell me how you would handle these question if you wanted to make the best impression
Feel free to provide input or comment an any line item.
Thanks!
As far as (3) is concerned, consider a shared PC. User A logs into a website using their site based user name/password. Does a whole load of work and shuts down the browser. USer B then comes along and on the same PC logs into the same site using their details. However, they will get the cookie from User A and be redirected to the last page they saw. This happens because Cookies are tied to the browser / OS user, where as you are potentially applying the site security separately in the application.
In this situation you would either need to put the user name into the cookie (encrypted) or use a server side method to store the location
Here are my thoughts:
They might be looking for Master Pages, but my first thought here was whether you're going to cache this user data, so you're not making a database query every time they hit a new page. To really impress them, you might mention partial caching techniques so that the repetitive portions of the page don't even need to be re-rendered with each page load.
I think you're right: they're helping you to conclude that the session state is an appropriate place to cache the user data. Just be sure you ask the appropriate questions, like "How many users?", and "How much data per user?"
The cached data could be used to keep track of the last-requested page, and when the user's session expires, you could save this data into a database table to be retrieved next time they log in.
That third item is awfully tricky. What if the user was last looking at an object that has since been deleted? What would be the intended behavior if a user logged in from one computer, did some work, and then logged in simultaneously from another computer or browser? I'd be sure to ask these kinds of questions, not least to show that I understand the implications of a requirement like this. If their responses lead you to believe that they're looking for a simple solution, go with the simple solution. Otherwise, tweak your response to be only as complicated as necessary.
Just a small thought.. If the system are running in a "Farmed" environment the Session data can be cleared and need to be handled some way.
http://www.beansoftware.com/ASP.NET-Tutorials/Store-Session-State-Server.aspx
I was wondering if it is even possible to interact with other websites using my own.
Here is the scenario:
Lets say I have a Lockerz account, which is a place where you do daily tasks to earn points. Once a month you can redeem those points to get prizes such as an ipod, macbook, or other items. I know that sounds rediculous, but stay with me.
For someone to gain membership to this website they must be invited by a member. So I get your email address then log in to my account, then send you an invite from there.
What I want to do is create a website where a user enters their email into a textbox and presses a submit button. From there the program, behind the scenes, sends my login information, and the users email address to lockerz and sends the invite. All without ever leaving my site.
I have worked with ASP.NET with VB codebehind for a while now, so I understand the basics of that. I am just wondering if what i want to do is even possible. If so, can someone redirect me to a tutorial or guide of some kind that will give me a basic knowledge on this.
Thanks
You'll have to work down at the HTTP level, sending POST and GET requests.
Fortunately, .NET has the WebRequest and WebClient classes to help you.
WebClient would probably be your best starting point... But I would hang on a second.
Websites like this tend to employ some pretty intense fraud-protection. Banning, blocking or at least ignoring actions when multiple accounts use one IP, or otherwise do things in a predictable pattern.
WebClient isn't going to load up the JavaScript either so you might you can't access required parts of the page.
Either way, you don't need to do this on your webserver - I'd start off by writing it initial connect code locally as a simple script. It'll make testing it a lot faster.
we have some application that this is vital to prevent users from opening multiple tabs/windows per session on the website ?
Edit:
The reason is that those pages communicate with flash and we cannot know on server side whether the user has two windows open or not.
Of course you can suggest to make those changes in application design so it will use Flash Media Server as "token generator" but we cannot allow ourselves to change the infrastructure without good reason because it can take months
This is a bad idea - you are restricting how the user expects their browser to behave.
Don't do it.
The only way I could think of to reliably do such would be to have a session that kept track of a token which was updated each time a page was requested - links on the served page would all include the token, and when a page was loaded using that token, a new token would be generated (in essence, only allowing any page's links to be valid for a single use). However, this would break things like the Back button and whatnot, and thus isn't a very good solution.
What is so important that you have this requirement in the first place? Is there any way you could re-think your interface so as to avoid such?
If limiting the user to 1 interface at a time is vital to the app, you should consider writing it as a desktop application instead of a web application.