I've already tried these methods:
System.Net.Dns.GetHostName
Environment.MachineName
My.Computer.Name
Environ$("computername")
Each returns APPDEV, which I assume is the name of the server hosting my web page.
I've even asked friends to try my page with these methods and they see the same thing.
How can I get it to return the PC name entered at initial setup, like Joseph-PC?
Since the browser won't tell the computer name to the server, a web page is (thankfully) not able to know your computer's name.
You can try HttpContext.Current.Request.UserHostName. Similarly, UserHostAddress retrieves the IP of the client. But this information might not be valid in most circumstances due to (legitimate) privacy or network (NAT, Proxies, ...) reasons. So I wouldn't rely to strong on the presence or validity of the data.
If you are provided an IP address in UserHostName, you can use System.Net.Dns.GetHostEntry to make a DNS reverse lookup to find the name. This also might not work under all circumstances as not every client is registered at a DNS server.
Related
I'm familiar with mailto:// links; that's not what this is about.
This is more akin to Sniper Links, which are useful to reduce friction in the process of confirming a new user's email address. We've just sent the user an email, and we want to give them a one-click way to go find it.
Sniper Links, as described at the link above, are great for that, but they're limited, in that:
The user must have a web-based email service.
We must be able to determine the mapping between email hostname and email provider (e.g. "some.guy#gmail.com" should go to the Gmail interface).
Those are mostly solved problems. Most people these days do use web-based email, and many who instead choose to use dedicated apps can use a web-based client. This is not universal, of course.
Mapping between hostname and provider is sometimes trivial (like the #gmail.com example above), sometimes not (#somecompany.com -> Google Apps is less obvious). If it's not directly obvious from the hostname, an MX record lookup will reveal the truth in the case of Google Apps and a most of the other big names in corporate email hosting. Services like ZeroBounce offer APIs to do the lookup and translation for you, for a fee.
But there are users whose email addresses do not have web interfaces, or for whom the URL of the web interface is not easily determined. For these users, I'd like to be able to bring up their preferred email client (assuming the browser -- or the underlying OS -- knows what it is).
I know that a mailto:// link will launch the default email client (whether web or app) and start composing a new outgoing message.
From a web page, is there a way to launch the default email client without starting a new outgoing message? I'm assuming this would take the form of a URI scheme, but it could also be a JavaScript API call or something else entirely.
Bonuses:
Also cause it to navigate to the inbox
Navigate, search, or filter such that we're likely to find our specific message (based on sender, date, subject, mailbox, etc)
Navigate to the precise message we just sent
No, that is not possible. Browsers won't open Apps "without" a reason. This could also be a major security risk, if they would do.
About this issue I read that the browser sends the cookies as follow
The more specific the path, the higher the precedence
I have two cookies in browser
jsessionid=avalue domain some.example.com
jsessionid=bvalue domain.example.com
when i request for http://some.example.com these cookies will be sent to server in the order of
jsessionid=avalue
jsessionid=bvalue
am i right?
and assuming that request is welcomed by Weblogic server, how weblogic reacts to this situation?
as you know jsession id is used to determine the session id in weblogic. this is a really critical issue for me.
Thanks.
You are right that more specific the cookie path, the higher the precedence. However, in your case, the difference is the domain between two cookies, not path. The precedence based on other attributes, including the domain, is unspecified, and may vary between browsers. This means that if you have set cookies of the same name against “.example.org” and “some.example.org”, you can’t be sure which one will be sent back. http://www.sitepoint.com/3-things-about-cookies-you-may-not-know/
Edit based on comments:
I would recommend you using two different cookie-names if your have two war deployed together. The default session cookie name is jsessionid, but it is configurable in the weblogic.xml.
<session-descriptor>
<cookie-name>jsessionid_app1</cookie-name>
</session-descriptor>
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.
If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
Lets say I have "admin" folder in my public_html and I don't want anyone except me to be able to access it. What if instead of password protecting it (using apache htaccess) I just rename it to "admin-7815696ecbf1c96e6894b779456d330e" and leave it open (with disabled folder indexes of course)?
People usually freak out from such "solution" as it seems extremely vulnerable. But is it really any worse than password protecting? I can't think about any major security risks comparing to password protecting. Would anyone be ever able to find out a name of this folder?
For a personal site, it's probably OK - but only you know the value of what you are protecting. One thing to be wary of is if you have webpages in that directory that link to external sources - by clicking a link to one of those external URLs you will (probably) pass on your "secret" url in the HTTP Referrer header. Also, it only takes on link back to your "secret" url and robots and spiders could be all over it and then you'll find it in Google. So, be very careful!
Bad idea - It's basically security by obscurity.
This is the sort of thing you'd use to protect a phpbb /install/ folder during an install, but not as a permanent solution.
Yes its a bad idea.
If you don't use a password, other systems won't treat it as such.
For example, your browser will now cache that url in its history. It won't do that automatically for passwords (at least not Firefox)
What about the list permission? What about internet hops, they'll see your URL.
If you start going around the security system, the security system won't know you want to be secure.
EDIT
Another way to think about it is, when software sees a password it goes, "This is an security issue and I will treat it as such." But for URLs, it goes "Meh, another piece of data"
Contrary to what others have said, this is not security through obscurity, and depending on how the random folder name is assigned, and how that name is protected, this can be a very secure solution.
First, choose the folder name from a large "space". Due to the size of the number in the question, it looks like that has been done. Personally, I'd choose a number randomly in a range up to between 2112 or 2128, then encode it to text using hexadecimal (base-64 would work in some contexts, but it's not handy for directory names).
The random component should be chosen from a cryptographic quality random number generator.
Then, protect the random name by transmitting and storing it only on secure media. This means, for example, only accessing the contents of the directory over HTTPS. Without SSL, an man-in-the-middle would learn the secret directory name and have unrestricted access.
If this is done by an administrator for their own use only, it's a quick and easy solution. If multiple parties need access to the directory, user names and passwords (which must also be transmitted only over a secure channel) quickly become more convenient because rights can be granted only by an administrator and can be revoked without affecting other users.
As Pyrolistical was saying, a randomized URL isn't protected with the same degree of care as a password would be. There's a lot of security research that goes into the systems that store and transmit passwords, and if you just use a randomized URL instead, you get none of that. (Well, you can force HTTPS for the URL, that gives you some benefit) But if you just want to deter casual snoopers, it's probably good enough. I've used that technique in the past when I wanted to share a URL with a few people, given that the data stored at the URL wasn't especially sensitive.
As for whether the randomized URL approach is appropriate for you, it depends - what web pages can you access from it? Typically "admin" means things like system control apps or database interfaces (phpMyAdmin and the like), and those sorts of things I wouldn't trust to a randomized URL scheme. Basically, if the web pages you're trying to protect are things that allow you to make changes to the system, go with password protection. But if they're read-only monitoring apps, like server statistics (and if there is no sensitive or personally identifying information involved), a randomized URL might be fine.
Honestly, though, why wouldn't you just set up password authentication, given how easy it is?
This is a form of security through obscurity - and it's bad security.
I use a random folder name with htaccess password and an SSL certificate. The password is a simple fallback, just in case someone clever (say the dude running the IT at the coffee shop) is able to get between your computer and the internet. The SSL encryption is necessary since htaccess passwords are not encrypted.
Whatever you do, make sure you don't have a link anywhere to your page.
I'd say it takes less effort to say, just kick on HTTP authentication in apache than it is to remember some 32+ character gibberish domain name.