Currently, archivists have to seek permission from webmasters of every single site before they are able to take snapshots and retain data.
My UK websites have been archived for years. Nobody asked me.
of database credentials or having different area, including duplicate pages, that handle the different database credentials.
Why would you have duplicate pages? You store the database connection credentials in a session, or even the database connection object. When they login, they change credentials and run with those.
The user can see the table structure, perhaps the view definition, but not the data they have no rights to.
You deny select on the table, and grant access to the view. The view contains a constraint that forces the view only to return the data the connecting user is allowed to see.
I have implemented this in Postgres/PHP.
You have a group role that has read access to the public tables (eg products). The webserver runs, by default, at this user level.
When a user logs in, they reconnect to the database. They are in two groups now, the same one the webserver runs in by default, and another, which gives them access to their view
To CREATE users, you have an insert trigger in a users table to which the webserver user has INSERT rights, which then creates a new role with the required credentials.
Is it more work than a simple users table and single sign on? Yes. Is it a more sound methodology than SSO? Yes.
You wouldn't have SSO in a corporate environment, why should you have it in a web environment?
I remember once sitting opposite a guy in the office who installed windows and repaired desktops. A nice enough guy. One day we were talking about career plans and he said "I'm probably going to do something else soon. I don't want to be an engineer all my life".
Compressing gasses generates huge amounts of heat, which if not captured, is waste heat. Similarly decompressing gases loses heat - that is why aerosols are cold, and is how refrigeration works.
Compressed air as a means of energy storage is a bad idea.
No more night-time builds means agile is possible?
on
Becoming Agile
·
· Score: 1
I'm not too young to remember when a software change meant an overnight build before testing could be done the next day. And then testing involved aspects of system performance which simply don't apply in many environments today - memory leaks, null pointer exceptions, DLL hell, and so on. There was a much stronger case for a more rigorous and pedestrian process, because the costs of change were higher. Being able to change and test code on the fly is something to to be taken advantage of.
That doesn't mean methodology should be thrown out of the window. A solid, lean, clean, transparent, demarcated set of classes to describe the general system and initial problem will give you flexibility to change. Keep your business, data and presentation layers separate. Always maintain stable interfaces. It doesn't have to be dogmatic.
T Series - bulletproof, robust, great with Linux, go forever. Also IBM/Lenovo provide fantastic replacement manuals giving descriptions of how to disassemble the unit step by step. I repaired an old T23 the other day and it's fantastic.
Also, Thinkpad Docks are great and cheap. I have a dock at home and at work and just shuffle the machine back and forth.
Never looked back.
A manual car is an advantage in many environments with changing road conditions and a variety of terrain (i.e. not most of the continental U.S.). If you want full control of your vehicle, you need a manual. If not, use an automatic. A bit like Linux and Windows.
If hate isn't a crime, why is inciting hatred a crime? This is one question the liberal fascists can't answer. Inciting violence is a crime, because violence is a crime, commissioning a crime is a crime. But hatred?
Liberals, not being people who like taking responsibility for their own actions, like the idea that nebulous things such as "speech" can be held responsible for events. Ergo, punish the speech.
The problem with "inciting hatred" is that it's such a nebulous term that anything can be interpreted in that way by even the most hypersensitive paranoiac and before you know it, you're not saying anything for fear of being arrested. For some people, saying that sodomy is grotesque is enough to merit a penalty.
Britain's Labour government are a sad, sad, desperate, miserable bunch of barrel scraping nation destroyers. We were owed an election years ago.
Keeping your business and presentation layers separate is the key to ensuring that your options are open in future. I'd like to think that I could take my php web app and put it into a php-gtk application without much extra work.
I could see a time when that happens somewhere down the line when the same app is basically offered in web or desktop format. There's definitely a time and a place for desktop apps. The web is a pretty square peg for the round holes of business, though you can get away with a lot.
Re:SOA - a backwards step
on
The Zen of SOA
·
· Score: 1
SOA isn't procedural.
OK, so, how in SOA would I instantiate a class, use a set method to change a property, call various methods on that class, change the property again, call the same methods again, all within the same block of code, all reusing the same database connection and other resources? Or how would I use one SOA service instance as a method parameter to another service instance and then act upon get and set methods within it?
I've got nothing against RPC per-se, but the idea that it's a panacea or a substitute for proper programming is misleading. It has a potential to be a nightmare, revolving your infrastructure around stateless and crude networked methods, which is all it ever seems to be. It also has the potential to spawn endless apps on endless platforms leading to a management hell further down the line, when what you need to be doing is sharing libraries on the same platform that guarantee efficient use of resources.
Yes, platform neutrality is appealing, but platforms offer huge benefits - user management, auditing, access control, resource management, etc, etc.
We love the idea of the network and the internet because they've brought us so much but the fact is those are sub-optimal paradigms. HTTP is crap. Web applications are a massive compromise of usability versus accessibility. SOAP and RPC enable machines to talk to each other across the wire easily. But be honest, if you didn't have to, why would you choose to?
SOA strikes me as a backwards step for an IT operation, and an excuse for not consolidating and sorting out your infrastructure.
The point of OO is that you can gain the benefits of polymorphism and inheritance, the ability to reuse code and build up a modular and flexible code library. That's why the world has moved away from procedural languages.
SOA is the idea that everything can be reduced to XML being fired backwards and forwards. If it's just access to data that's the issue, use a proper RDBMS. Use views, triggers and stored procedures if you want that data presented to different people in different ways. Use networked clients - after all, most of the time SOA is used within the enterprise, and most of the time enterprises control their software stacks and networks.
Although I heartily agree with the EU on this, I don't see it as a vindication of our ongoing membership.
This (and many other matters), are deeply alarming developments in British democracy, but they have come about because of a constitutional failure, largely brought about by the dilution of our democracy and its compromise by our membership of the EU itself. There are many other factors, including the failure, malicious or otherwise, of our left-wing education system to educate people about their history and country.
Sadly, I think leaving the EU is the prerequisite to rebuilding a very broken and disordered Britain and restoring faith in democratic institutions.
In fact, the whole point of hashes is that they give completely different results even with the smallest differences between files or strings.
Think about it. Imagine if the hash for the word "foo" was 45Ht56B, and you knew that. If the hash for "f001" was 45Ht56C or 45Ht56B4, then you could deduce a password simply by looking at a hash.
I've always understood that Perl has never been sold as a technology to build complete systems with (although it can be done), but as a multi-purpose toolkit with the emphasis on systems administration and systems integration.
It's unsurprising if code has developed on an ad-hoc basis.
Yet Sauber still can't win a race.
Currently, archivists have to seek permission from webmasters of every single site before they are able to take snapshots and retain data. My UK websites have been archived for years. Nobody asked me.
Why not? What's the difference between code to manage users whether in a table or in the native RDBMS?
of database credentials or having different area, including duplicate pages, that handle the different database credentials.
Why would you have duplicate pages? You store the database connection credentials in a session, or even the database connection object. When they login, they change credentials and run with those.
The user can see the table structure, perhaps the view definition, but not the data they have no rights to.
You deny select on the table, and grant access to the view. The view contains a constraint that forces the view only to return the data the connecting user is allowed to see.
I have implemented this in Postgres/PHP.
You have a group role that has read access to the public tables (eg products). The webserver runs, by default, at this user level.
When a user logs in, they reconnect to the database. They are in two groups now, the same one the webserver runs in by default, and another, which gives them access to their view
To CREATE users, you have an insert trigger in a users table to which the webserver user has INSERT rights, which then creates a new role with the required credentials.
Is it more work than a simple users table and single sign on? Yes. Is it a more sound methodology than SSO? Yes.
You wouldn't have SSO in a corporate environment, why should you have it in a web environment?
If your code is running at the correct privilege level, SQL injections should be completely irrelevant.
If your user is connecting with the correct credentials, they should only be able to see public data and their own records, nothing else.
This is implemented by using views in the database, and only allowing users rights to views, not tables.
If your website user is connecting with credentials that allow a crafted SQL query to see priveleged data, you have set everything up wrong
If you have set everything up correctly, even a successful SQL injection will only return data the user can see
Been using Quanta on Ubuntu for years now. Fantastic. Can't think what else I would need.
And when you are 40, it is 1/40th. So your experience of a year is ever contracting.
I remember once sitting opposite a guy in the office who installed windows and repaired desktops. A nice enough guy. One day we were talking about career plans and he said "I'm probably going to do something else soon. I don't want to be an engineer all my life".
Compressing gasses generates huge amounts of heat, which if not captured, is waste heat. Similarly decompressing gases loses heat - that is why aerosols are cold, and is how refrigeration works. Compressed air as a means of energy storage is a bad idea.
I'm not too young to remember when a software change meant an overnight build before testing could be done the next day.
And then testing involved aspects of system performance which simply don't apply in many environments today - memory leaks, null pointer exceptions, DLL hell, and so on. There was a much stronger case for a more rigorous and pedestrian process, because the costs of change were higher. Being able to change and test code on the fly is something to to be taken advantage of.
That doesn't mean methodology should be thrown out of the window. A solid, lean, clean, transparent, demarcated set of classes to describe the general system and initial problem will give you flexibility to change. Keep your business, data and presentation layers separate. Always maintain stable interfaces. It doesn't have to be dogmatic.
T Series - bulletproof, robust, great with Linux, go forever. Also IBM/Lenovo provide fantastic replacement manuals giving descriptions of how to disassemble the unit step by step. I repaired an old T23 the other day and it's fantastic. Also, Thinkpad Docks are great and cheap. I have a dock at home and at work and just shuffle the machine back and forth. Never looked back.
A manual car is an advantage in many environments with changing road conditions and a variety of terrain (i.e. not most of the continental U.S.). If you want full control of your vehicle, you need a manual. If not, use an automatic. A bit like Linux and Windows.
Eh?
If hate isn't a crime, why is inciting hatred a crime? This is one question the liberal fascists can't answer. Inciting violence is a crime, because violence is a crime, commissioning a crime is a crime. But hatred?
Liberals, not being people who like taking responsibility for their own actions, like the idea that nebulous things such as "speech" can be held responsible for events. Ergo, punish the speech.
The problem with "inciting hatred" is that it's such a nebulous term that anything can be interpreted in that way by even the most hypersensitive paranoiac and before you know it, you're not saying anything for fear of being arrested. For some people, saying that sodomy is grotesque is enough to merit a penalty.
Britain's Labour government are a sad, sad, desperate, miserable bunch of barrel scraping nation destroyers. We were owed an election years ago.
Keeping your business and presentation layers separate is the key to ensuring that your options are open in future. I'd like to think that I could take my php web app and put it into a php-gtk application without much extra work.
I could see a time when that happens somewhere down the line when the same app is basically offered in web or desktop format. There's definitely a time and a place for desktop apps. The web is a pretty square peg for the round holes of business, though you can get away with a lot.
OK, so, how in SOA would I instantiate a class, use a set method to change a property, call various methods on that class, change the property again, call the same methods again, all within the same block of code, all reusing the same database connection and other resources? Or how would I use one SOA service instance as a method parameter to another service instance and then act upon get and set methods within it?
I've got nothing against RPC per-se, but the idea that it's a panacea or a substitute for proper programming is misleading. It has a potential to be a nightmare, revolving your infrastructure around stateless and crude networked methods, which is all it ever seems to be. It also has the potential to spawn endless apps on endless platforms leading to a management hell further down the line, when what you need to be doing is sharing libraries on the same platform that guarantee efficient use of resources.
Yes, platform neutrality is appealing, but platforms offer huge benefits - user management, auditing, access control, resource management, etc, etc.
We love the idea of the network and the internet because they've brought us so much but the fact is those are sub-optimal paradigms. HTTP is crap. Web applications are a massive compromise of usability versus accessibility. SOAP and RPC enable machines to talk to each other across the wire easily. But be honest, if you didn't have to, why would you choose to?
SOA strikes me as a backwards step for an IT operation, and an excuse for not consolidating and sorting out your infrastructure.
The point of OO is that you can gain the benefits of polymorphism and inheritance, the ability to reuse code and build up a modular and flexible code library. That's why the world has moved away from procedural languages.
SOA is the idea that everything can be reduced to XML being fired backwards and forwards. If it's just access to data that's the issue, use a proper RDBMS. Use views, triggers and stored procedures if you want that data presented to different people in different ways. Use networked clients - after all, most of the time SOA is used within the enterprise, and most of the time enterprises control their software stacks and networks.
SOA - Sort Out your Architecture.
Although I heartily agree with the EU on this, I don't see it as a vindication of our ongoing membership.
This (and many other matters), are deeply alarming developments in British democracy, but they have come about because of a constitutional failure, largely brought about by the dilution of our democracy and its compromise by our membership of the EU itself. There are many other factors, including the failure, malicious or otherwise, of our left-wing education system to educate people about their history and country.
Sadly, I think leaving the EU is the prerequisite to rebuilding a very broken and disordered Britain and restoring faith in democratic institutions.
$speak_text = $speak_text.' eh?';
In fact, the whole point of hashes is that they give completely different results even with the smallest differences between files or strings. Think about it. Imagine if the hash for the word "foo" was 45Ht56B, and you knew that. If the hash for "f001" was 45Ht56C or 45Ht56B4, then you could deduce a password simply by looking at a hash.
What on earth do you have to do to a 30 ton transformer that requires complete replacement?
They didn't LOSE the data, they lost a COPY of it,
I've always understood that Perl has never been sold as a technology to build complete systems with (although it can be done), but as a multi-purpose toolkit with the emphasis on systems administration and systems integration. It's unsurprising if code has developed on an ad-hoc basis.
What?