Two problems. Firstly, that involves sending username and password with every request. The more modern "Digest" authentication may solve this problem, but wasn't actually supported by anything, last time I checked (admittadely that was a while ago).
Secondly, and more significantly, we allow users to authenticate themselves in several different ways (against university wide ITS' LDAP server, the department's LDAP server, or against an application-specific authentication server), and there is no way that I'm aware of including that selection in the authentication request. The idea of making user credentials of the form <username> "@" <auth type> did occur, but I suspect the user's wouldn't appreciate it.
Seperately, in most cases authentication is managed by the web server - because we use servlets, we can have it managed by the web application, but I believe that its quite tricky to do under, for example, Apache. Anyone want to tell me I'm wrong?
Well put, thank you. So what we really want, is a simple way of avoiding profiling cookies. Mozilla gets close, if you block all third party cookies. Alternatively, use Mozilla to block all cookies and then selectively allow sites. Konqueror may be best for the latter - it pops up a requestor when a cookie is received, and allows you to block/allow all cookies from that domain (along with other options.
I write web applications for a living. The main application I'm working on requires a login. That's fine, but we then have to keep track of who has logged in, and to which account. We could do this by IP, but its insecure (IP spoofing) and would cause problems with multiple log-ins from the same IP (NAT, etc). We could have the user send their username and password as part of each and every URL they request, but that has various problems ranging from passwords showing up in usage stats, to likelihood of being intercepted (most of our users don't use SSL, for reasons not worth explaining here).
Instead, we give them a unique session ID. These are generated to be difficult to guess, making it difficult (if not virtually impossible) for one user to hijack another's session. We then try to give the user this session ID as a cookie. We do attempt a form of fail-over, whereby if the cookie is rejected we write the session ID into all auto-generated URLs, but it isn't perfect. When the browser closes, this cookie is deleted automatically.
So, in this case, what's your objection?
Re:This review needs a Disclaimer
on
The Big Kerplop
·
· Score: 1
Screw this pure hypothesis lark, this may be the best/only chance I have (err, Slashdot archives aren't kept too long, right?)! The only question is, what sort of scar and where? Should I go for some huge gash on the face, or perhaps just some tasteful burn marks on one hand? The selection is endless...
BTW, for those who read/. and know me IRL, no, you don't need to start keeping sharp/flammable objects away from me. Equally, offering to lend me sharp/flammable objects is not a good thing, either.
This problem doesn't actually worry me that much. Moving in general worries me, but given the general up-to-dateness of appliances supplied with the flats we rent (one came with a gramophone player!), I'd actually be quite suprised if this technology turned up in any of them. The point was more to make people think about the problems likely to be encountered by anyone that moves house/office a lot.
Okay, so the article is about the office, but lets talk about this technology in general. I am currently renting, and have so far had to move 16 times in the last 6 years (generally had extrodinarily bad luck finding somewhere permanent). Obviously, as we're renting, things like the fridge, washing machine, etc are part of the flat, and do not move with us.
So, what happens when we move? Does the new fridge try mapping me to its old owner? Maybe it decides I'm an intruder, and throws old milk at me? Are all my preferences written to CD by the old house, for loading into the new, because I'm really sure all the manufacturers will make their equipment compatible!
Additionally, I don't know about anyone else, but I'm always somewhat unnerved by moving. I'm generally a little more tense for a week afterwards, it wrecks havoc with my sleep pattern, this sort of thing. How well will this technology cope with that sort of event?
Well, in a refreshing move, the higher-ups have decided not to change, conditional on a few minor changes being put into the existing system. Just thought I'd mention for anyone that cares:)
Two things I should add. Firstly, my job doesn't atually depend on the system, and secondly I don't have to use the alternative. In fact, this may result in me being paid, for the next year at least, to maintain the system they aren't using. So, I'm really not all that bitter.
Good guess on the real reasons as to why the changeover, you are probably quite close to being correct. Couple of details, like its actually a committee that's doing this, and my boss is on my side, but close enough.
Oh well, I figure we re-package the system with added buzzword compliancy, print the manual in one of those nice ring binders and present it as a new idea this time next year. Scary thing is, it'll probably work too.
I've got this kind of situation at work. The department I work in is replacing the system I've written and am now maintaining, with a different system that's less suitable for the job and costs 4 (yes, FOUR) times my salary, per year.
Oh no. No no no no NO. If someone spoofs millions of spams, coming from your e-mail address, and you end up being sued for vast amounts of money as a result, would you consider it fair? It is in no way Microsoft's fault that someone faked their address, and as such they shouldn't be sued for it.
I'm not sure they should be suing for it, either, although I'm strongly of the opinion that pretending to be someone else, in whatever medium, should be illegal. I believe in the right to anonymity, not the right to tell everyone you're me!
ANd as for the health bennifits, yeah, its great. Why last january, i would have loved to have had to walk everywhere theough the snow and sleet, much better than taking my heated automobile. THe colds I would catch would definetly help my immune system, and the average health of the nation would go up as all the old people died from longer walks in bad weather.
Walking during bad weather isn't nice, but you get used to it. I've been walking 4-6 miles a day, for the last 6 years (ever since I started college), and St. Andrews is really quite unpleasant in winter. Heck, its not that nice in spring (we had hail on Wednesday!). However, this has had no noticable change on how often I get ill. Same for my flatmates. Obviously you have to dress for the weather, but that's nothing more than common sense.
Its a trade off. You get a little cold/damp, and not only do limited resources like fossil fuels last a lot longer, but the environment isn't such a mess either. I think its worth it.
We've got a lot of systems pretty much ready for IPv6, but we're waiting on the infrastructure (routes, DNS, etc) to be set up. Latest versions of RedHat Linux, the *BSDs, and Windows XP all support IPv6. I believe there's a test IPv6 implementation for Mac OS X aswell.
I imagine a lot of people are in the same situation, waiting on IT departments without enough time to make the changes.
Oh, at home... well, the equipment is simple off the shelf stuff, I doubt any of it supports IPv6, and my ISP would probably just look confused if I mentioned it.
Well, I upgrade using "rpm -F", so it works fine for me. I did mean to point out its not a complete solution, my bad. And if it makes you feel better, I'd have modded up your original post, if I had points.
Or, failing that, mount the CDs using loopback, and then check the signature. Something like this:
mount -o loop shrike-i386-disc3.iso/mnt/cdrom
rpm --checksig/mnt/cdrom/RedHat/RPMS/*.rpm
You'll need to have downloaded the RedHat public key, which you can get from "pub/redhat/linux/8.0/en/os/i386/RPM-GPG-KEY" of your favourite RedHat mirror, and then import with a command like:
The difference being that a buggy Java app is far less likely to result in an exploit.
I fail to see how? In the case of an applet, sure, because you've got a security wrapper, but in a stand-alone application I don't see why its less likely to have security holes?
I'd disagree that no particular language is faster. Lets start with assembly, which on most platforms is faster than anything else (RISC systems can be a different case, but work with me here). C is not that much higher level than assembly, and so allows the programmer a far greater level of control over how things run.
For example, in Java, if I want to process a string (converting control characters to spaces, for example), I either have to call a method to fetch each character, or first convert the string to a char array, then test each character then convert the result back to a String instance. In C, I can use function pointers, saving me the conversion to/from a char array.
Fine, its not a massive overhead, but the point stays. I have code that does 20-30 significantly more complex sets of string processing for most interactions with the user, and that adds up to a noteworthy slowdown.
Conversely, I'm currently working in Java, because we've got more processor time than programmer time. I just felt a need to defend C.
This is a beta. With any luck, they will release the final version on its own CD, and you'll be able to buy it, and everything. Maybe I'm wrong, but that would make sense to me...
I very definately agree. Academics and system administration do not mix - to most of them, system administration involves installing RedHat on the prebuilt box they bought, clicking the "Install everything" box, and then leaving it well alone unless it stops working completely. Suffice to say, security problems are frequent, as are house of cards problems (where one thing breaks, and everything else, that was hanging on by a thread, follows it).
Teaching administration skills, IMHO, should involve setting up computers with problems, letting the students work through the solution, and the HD being wiped and replaced with the backup from before, after.
It would be nice students could be allowed to admin systems, but the university has to provide a service, and if all the systems are down because a student broke something, its their necks on the line. Also, without root there's not a heck of a lot you can do - basically they can install software and that's about it.
I'm staff at the school of computer science at a university, I administrate 6 different servers for my research group, and they won't let me anywhere near the main servers - I think its reasonable to say we can forget them letting students anywhere near them.
I find the idea of something being too technical for e-mail quite funny. I explain complex concepts in two ways; in e-mail, or through the use of hand puppets. Really, hand puppets work great - they encourage you to think in really simple terms, and the person you're talking to, to relax. Admittadely, they generally work better if you're talking to friends, and definately not your boss, but its worth trying sometime.
On a more serious note, I find e-mail allows me to collect my thoughts more coherently when sending, and gives me something I can refer to receiving, which is a lot more useful to me than a phone conversation.
Another possibility is that they're getting lots of the simpler components made up in advance. Cases, power supplies, that sort of thing. This might help avoid some of the problems they had last time with not being able to meet demand (although meeting demands for the complex chips is still likely to be the bigger issue).
Slashdot Mirror
Two problems. Firstly, that involves sending username and password with every request. The more modern "Digest" authentication may solve this problem, but wasn't actually supported by anything, last time I checked (admittadely that was a while ago).
Secondly, and more significantly, we allow users to authenticate themselves in several different ways (against university wide ITS' LDAP server, the department's LDAP server, or against an application-specific authentication server), and there is no way that I'm aware of including that selection in the authentication request. The idea of making user credentials of the form <username> "@" <auth type> did occur, but I suspect the user's wouldn't appreciate it.
Seperately, in most cases authentication is managed by the web server - because we use servlets, we can have it managed by the web application, but I believe that its quite tricky to do under, for example, Apache. Anyone want to tell me I'm wrong?
Well put, thank you. So what we really want, is a simple way of avoiding profiling cookies. Mozilla gets close, if you block all third party cookies. Alternatively, use Mozilla to block all cookies and then selectively allow sites. Konqueror may be best for the latter - it pops up a requestor when a cookie is received, and allows you to block/allow all cookies from that domain (along with other options.
I write web applications for a living. The main application I'm working on requires a login. That's fine, but we then have to keep track of who has logged in, and to which account. We could do this by IP, but its insecure (IP spoofing) and would cause problems with multiple log-ins from the same IP (NAT, etc). We could have the user send their username and password as part of each and every URL they request, but that has various problems ranging from passwords showing up in usage stats, to likelihood of being intercepted (most of our users don't use SSL, for reasons not worth explaining here).
Instead, we give them a unique session ID. These are generated to be difficult to guess, making it difficult (if not virtually impossible) for one user to hijack another's session. We then try to give the user this session ID as a cookie. We do attempt a form of fail-over, whereby if the cookie is rejected we write the session ID into all auto-generated URLs, but it isn't perfect. When the browser closes, this cookie is deleted automatically.
So, in this case, what's your objection?
Screw this pure hypothesis lark, this may be the best/only chance I have (err, Slashdot archives aren't kept too long, right?)! The only question is, what sort of scar and where? Should I go for some huge gash on the face, or perhaps just some tasteful burn marks on one hand? The selection is endless...
BTW, for those who read /. and know me IRL, no, you don't need to start keeping sharp/flammable objects away from me. Equally, offering to lend me sharp/flammable objects is not a good thing, either.
That, and it scrunches the paper up...
Nah, we avoid the stuff like the plague too...
This problem doesn't actually worry me that much. Moving in general worries me, but given the general up-to-dateness of appliances supplied with the flats we rent (one came with a gramophone player!), I'd actually be quite suprised if this technology turned up in any of them. The point was more to make people think about the problems likely to be encountered by anyone that moves house/office a lot.
Okay, so the article is about the office, but lets talk about this technology in general. I am currently renting, and have so far had to move 16 times in the last 6 years (generally had extrodinarily bad luck finding somewhere permanent). Obviously, as we're renting, things like the fridge, washing machine, etc are part of the flat, and do not move with us.
So, what happens when we move? Does the new fridge try mapping me to its old owner? Maybe it decides I'm an intruder, and throws old milk at me? Are all my preferences written to CD by the old house, for loading into the new, because I'm really sure all the manufacturers will make their equipment compatible!
Additionally, I don't know about anyone else, but I'm always somewhat unnerved by moving. I'm generally a little more tense for a week afterwards, it wrecks havoc with my sleep pattern, this sort of thing. How well will this technology cope with that sort of event?
Well, in a refreshing move, the higher-ups have decided not to change, conditional on a few minor changes being put into the existing system. Just thought I'd mention for anyone that cares :)
Two things I should add. Firstly, my job doesn't atually depend on the system, and secondly I don't have to use the alternative. In fact, this may result in me being paid, for the next year at least, to maintain the system they aren't using. So, I'm really not all that bitter.
Good guess on the real reasons as to why the changeover, you are probably quite close to being correct. Couple of details, like its actually a committee that's doing this, and my boss is on my side, but close enough.
Oh well, I figure we re-package the system with added buzzword compliancy, print the manual in one of those nice ring binders and present it as a new idea this time next year. Scary thing is, it'll probably work too.
I've got this kind of situation at work. The department I work in is replacing the system I've written and am now maintaining, with a different system that's less suitable for the job and costs 4 (yes, FOUR) times my salary, per year.
Isn't bureaucracy great...
Oh no. No no no no NO. If someone spoofs millions of spams, coming from your e-mail address, and you end up being sued for vast amounts of money as a result, would you consider it fair? It is in no way Microsoft's fault that someone faked their address, and as such they shouldn't be sued for it.
I'm not sure they should be suing for it, either, although I'm strongly of the opinion that pretending to be someone else, in whatever medium, should be illegal. I believe in the right to anonymity, not the right to tell everyone you're me!
ANd as for the health bennifits, yeah, its great. Why last january, i would have loved to have had to walk everywhere theough the snow and sleet, much better than taking my heated automobile. THe colds I would catch would definetly help my immune system, and the average health of the nation would go up as all the old people died from longer walks in bad weather.
Walking during bad weather isn't nice, but you get used to it. I've been walking 4-6 miles a day, for the last 6 years (ever since I started college), and St. Andrews is really quite unpleasant in winter. Heck, its not that nice in spring (we had hail on Wednesday!). However, this has had no noticable change on how often I get ill. Same for my flatmates. Obviously you have to dress for the weather, but that's nothing more than common sense.
Its a trade off. You get a little cold/damp, and not only do limited resources like fossil fuels last a lot longer, but the environment isn't such a mess either. I think its worth it.
We've got a lot of systems pretty much ready for IPv6, but we're waiting on the infrastructure (routes, DNS, etc) to be set up. Latest versions of RedHat Linux, the *BSDs, and Windows XP all support IPv6. I believe there's a test IPv6 implementation for Mac OS X aswell.
I imagine a lot of people are in the same situation, waiting on IT departments without enough time to make the changes.
Oh, at home... well, the equipment is simple off the shelf stuff, I doubt any of it supports IPv6, and my ISP would probably just look confused if I mentioned it.
According to the FAQ you can compile it on Windows using Cygwin. On the subject of ports, Mac OS X users may be interested in MPlayer OS X.
Well, I upgrade using "rpm -F", so it works fine for me. I did mean to point out its not a complete solution, my bad. And if it makes you feel better, I'd have modded up your original post, if I had points.
Or, failing that, mount the CDs using loopback, and then check the signature. Something like this:
mount -o loop shrike-i386-disc3.iso /mnt/cdrom /mnt/cdrom/RedHat/RPMS/*.rpm
rpm --checksig
You'll need to have downloaded the RedHat public key, which you can get from "pub/redhat/linux/8.0/en/os/i386/RPM-GPG-KEY" of your favourite RedHat mirror, and then import with a command like:
rpm --import RPM-GPG-KEY
No, actually we want to die at the hands of the robotic minions of an evil AI that grew from an old chess program. Or something like that.
The difference being that a buggy Java app is far less likely to result in an exploit.
I fail to see how? In the case of an applet, sure, because you've got a security wrapper, but in a stand-alone application I don't see why its less likely to have security holes?
I'd disagree that no particular language is faster. Lets start with assembly, which on most platforms is faster than anything else (RISC systems can be a different case, but work with me here). C is not that much higher level than assembly, and so allows the programmer a far greater level of control over how things run.
For example, in Java, if I want to process a string (converting control characters to spaces, for example), I either have to call a method to fetch each character, or first convert the string to a char array, then test each character then convert the result back to a String instance. In C, I can use function pointers, saving me the conversion to/from a char array.
Fine, its not a massive overhead, but the point stays. I have code that does 20-30 significantly more complex sets of string processing for most interactions with the user, and that adds up to a noteworthy slowdown.
Conversely, I'm currently working in Java, because we've got more processor time than programmer time. I just felt a need to defend C.
This is a beta. With any luck, they will release the final version on its own CD, and you'll be able to buy it, and everything. Maybe I'm wrong, but that would make sense to me...
I very definately agree. Academics and system administration do not mix - to most of them, system administration involves installing RedHat on the prebuilt box they bought, clicking the "Install everything" box, and then leaving it well alone unless it stops working completely. Suffice to say, security problems are frequent, as are house of cards problems (where one thing breaks, and everything else, that was hanging on by a thread, follows it).
Teaching administration skills, IMHO, should involve setting up computers with problems, letting the students work through the solution, and the HD being wiped and replaced with the backup from before, after.
It would be nice students could be allowed to admin systems, but the university has to provide a service, and if all the systems are down because a student broke something, its their necks on the line. Also, without root there's not a heck of a lot you can do - basically they can install software and that's about it.
I'm staff at the school of computer science at a university, I administrate 6 different servers for my research group, and they won't let me anywhere near the main servers - I think its reasonable to say we can forget them letting students anywhere near them.
I find the idea of something being too technical for e-mail quite funny. I explain complex concepts in two ways; in e-mail, or through the use of hand puppets. Really, hand puppets work great - they encourage you to think in really simple terms, and the person you're talking to, to relax. Admittadely, they generally work better if you're talking to friends, and definately not your boss, but its worth trying sometime.
On a more serious note, I find e-mail allows me to collect my thoughts more coherently when sending, and gives me something I can refer to receiving, which is a lot more useful to me than a phone conversation.
Another possibility is that they're getting lots of the simpler components made up in advance. Cases, power supplies, that sort of thing. This might help avoid some of the problems they had last time with not being able to meet demand (although meeting demands for the complex chips is still likely to be the bigger issue).