|
|
That can't be real. Come on. How stupid an entire team has to be to let this run in production. Has to be a joke. And if this is intranet, why are you bothered with form based authentication? Just do AD look up or something.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
I want to believe this is a joke too and that an entire team cannot be that stupid...
But I'm not so sure
I once worked for a company who had their own "security framework".
The idea was that you entered a username and password, the application would use those to login to SQL Server and if that succeeded you were logged in.
So a user in SQL Server was a user in the system and a user in the system couldn't exist without a user in SQL Server.
It supported Windows authentication too.
The application had a form to enter new users and those users would be added in SQL Server too.
It was a WinForms application on intranet so I guess it wasn't much of an issue, but it's really not how to do authentication
I think we ran into some issues at one point though.
They built it when I was already an employee and I advised against it and advised a more "traditional" approach, but I was just a junior back then and according to the technical director this really was the best method.
Cost him months to build too
I just remembered the issue we ran into!
After a backup or some such, all users ended up being "orphaned" and everybody lost access to the database and the application.
Happened more than once too.
A 200+ employee company
|
|
|
|
|
Only thing then left was to hand over keys to data center to users.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
We were lucky our users were enormous digital illiterates
|
|
|
|
|
I had a client that was doing the same thing - fortunately they were updating their web app so I was able to rip all that out. However they also had code that would record every login event to a log file, recording the username and password in a publically accessible plain text file (within their LAN).
|
|
|
|
|
lw@zi wrote: How stupid an entire team has to be Just because it's a mid-sized organisation doesn't mean there's an "entire team". All too often the "IT Department" is one person (as a freelancer, I've been the "IT Department" to quite a few companies of that size and above). It may not even be an IT professional - this may be a tool knocked up for personal use, spotted by a manager, who said "roll that out to everyone and stick a username/password check on the front". If it's someone who spent 5 hours learning basic Javascript but no other IT background, it's no surprise stuff like this goes live. And it works so the manager would probably be delighted.
What I wonder more about is
if ("true" === "true") {
return false;
} Why???
|
|
|
|
|
The method is DoesUserWantToLogin, question is "Do you not want to login", response was true so return value was false. It is so straightforward. What is confusing you?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Not confused... just in wonderment!
|
|
|
|
|
I have a hard time believe that it is real...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I don't see the problem Just disable the dev tools on the login page so no-one can see the api call.
|
|
|
|
|
I especially liked the
<!-- Yeah buddy, that's the biggest issue here...
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
That was a comment from QA. Too much code in one file.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
This reminds me of iSpy! ...or it reminds me of an instructor who's trademark was every test had a 'find 10 things wrong with this code block' question.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Open Data is the logical extension of Open Source
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Someone went to a coding-bootcamp, and was so great at his work his code needn't be reviewed
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Here's my fantasy rewrite of some Javascript.
Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest.
JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};
Fantasy Rewrite
home
City 'Boston'
That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words.
What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance.
Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.
What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
|
|
|
|
|
I wold go with some Lisp dialect. It looks weird until you get used to it, then all other languages look hard to understand.
The reason I found it easy is because the grammer is so simple there's really not much to learn.
|
|
|
|
|
Smalltalk has similar properties - the syntax literally fits on an index card.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
BASIC.
The only problem with any of the modern BASIC variants is the the name.
It should have been changed years ago to something that sounds better.
BASIC is the direction that programming languages should have been taking for decades.
A programming language is a tool. A tool is something that makes work easier.
C, Java and the like make simple jobs complicated, and complicated jobs - well, we won't go there.
Unfortunately BASIC has been all but killed off because it scared the crap out of the C guys.
VB was arguably one of Microsoft's biggest successes - suddenly anyone smarter than a manager or an accountant could write useful programs. They weren't always fast, or efficient, but they solved real world problems, then and there.
And here lies one of the less understood issues with software - many, many programs are written as quick one offs to answer a question, or extract some data. They do not need the .NET framework or the latest C++ or Java support libs, or some horrendously expensive and complicated Studio Suite to create them
BASIC was able to do this AND produce high quality complicated full fledged applications.
And it still can.
My favourite is PowerBasic -
PowerBASIC[^]
There are a few others.
It seems to me that all the 'new' languages we see are based on C syntax.
A whole bunch of cryptic punctuation marks interspersed with some unreadable, unintuitive bits of code.
It's time to move on. C was never meant to last this long.
It was an interim replacement to FORTRAN, until the 'new' languages came along. Sadly they never did.
|
|
|
|
|
Up-vote for the comment on 'C'-style syntax (looking at you C#), but disagree about BASIC - way too wordy for it's own good.
It's all down to horses-for-courses really, isn't it?
But a programming language for (semi) non-programmers to do actual work (you know, get stuff done, at work) needs to have reasonably transparent syntax and not be cluttered with the kind of stuff systems programmers and computer science professors deem 'essential' for 'clarity' and nerd-'beauty'.
OK, apologies to systems programmers - their criteria are very different from the request in the original question...
I think the reason Python has become so popular (apart from fashion?) is that it does allow non-programmers to quickly grasp the essentials and actually do stuff - and if they need to then do more complicated stuff, it allows them to do that as well in a natural progression?
And because it's (slightly) less verbose that BASIC it makes it more human-readable(?)
It's a toughy...
|
|
|
|
|
Bravo!!!
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
|
Member 14564709 wrote: Unfortunately BASIC has been all but killed off because it scared the crap out of the C guys.
i like your thinking. Plz check out my git.
https://github.com/contextual-project/contextual.js/wiki
|
|
|
|
|
Hello,
The question must be looked at from several perspectives.
I would start by saying that if you give me 3 sliders to grade "practical", "concise" and "human readable", there is no way you will reach 100% on each, I would argue that not even an 80-80-80 is possible.
Everything is a trade-off, and you will sacrifice in one area because there are things you definitely want to keep in another, and those things have a cost. It is up to you to decide which area you want to favor. Or rather, which language you want to support based on your style as a programmer.
Then comes the question of the language's purpose. One should not compare a system language vs a scripting language for example. By nature, they have different purposes, have been build to solve different issues. One is compiled, the other is interpreted, and like it or not this has an impact on its design.
Each area you suggest deserve its own debate, almost.
"Human readable" for example. In your example, I would not want a very long hash table to be described without any special character. In the real world, large XML or JSON files are a reality. Imagine those without anything to identify what goes where. Tab separated ? or indentation dependent ? I personally think Python is an abomination for that reason alone, but there I am going against the majority, so let's avoid waking up the beast
But you see, right here, by giving more focus to "human readable", you have already lost in practicality. Trade-off as I said.
"Practical" : you mentioned "it has community, tools, …" => well those things are not the language itself, and they do not make it practical. The language itself should be self sufficient, you want to compare apples with apples. The fact that a language has a huge community is just showing its popularity, not its intrinsic worth.
If I look at my own experience in scripting languages, I have done many, and I firmly believe that the best of them is Lua, but the world favors Python. So which is more practical ? Probably Python if you look at the community and tools, but I think it is Lua for the human-readable part.
As for conciseness, I think it is not really the biggest problem. At some point, you have to tell the computer what to do. The real question is how much you want to work to get there. The real question is : "how much work should be accomplished by the programmer and by the compiler ?"
If it is hard to write, it is probably easy to parse (think C++).
If it is easy to write, it is probably hard to parse (think any high-level language).
I am still dreaming of a language that is as powerful as C++ but as easy to write as Lua.
|
|
|
|
|