|
My answer will make me sound like a Microsoft FanBoy but I will go ahead and offer it and attempt to back it up.
Learn ASP.NET Core (.NET Core).
Here's why.
1. Visual Studio Community is (basically and almost entirely) free.
2. The .NET Core includes everything you need to create true Enterprise Apps
a.) VSTudio dev environment - wraps up build, minifying JS,
b.) There's an entire plan for developing web apps but it is still open.
c.) You can build ReactJS or AngularJS later on top of your ASP.NET MVC site anyways (if you decide to go that way later
d.) Microsoft wraps up the basics you will most certainly use : C# (for backend), HTML created via generator (Razor), Asynchronous support (AJAX but better), jQuery is there, Bootstrap is there
e.) It is very modular -- only add what you need for your web app (everything is added via Dependency Injection of services)
f.) You get the package management (Nuget) to add custom things you need.
It's all wrapped up nicely and will get you there with solid patterns.
To get more detail read Dino Esposito's book, Programming ASP.NET Core, Programming ASP.NET Core[^]
or start with my intro article here on CP which will provide an intro and overview of more details why I think Microsoft is going to win in this area:
ASP.NET Core : Building Enterprise Solutions (Intro & Chpt 1 of N)[^]
|
|
|
|
|
Luca Leonardo Scorcia wrote: I am ready to ditch Web Forms
So what's the problem with Web Forms? If they get the job done, use them. I'm helping a colleague who has been 'out of the game' to get started with a Web Forms LoB application.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I have been working on an architectural reference application for that, having developed server code for a web API in C# and PHP, and client code in Angular (keep looking wistfully at Vu), Android and iOS. The web API is the linchpin of it all. The web API has EF in the backend, and I have even been trying to get it to work with ADFS. I wish I could put it out there, but my boss won't let me. On the other hand, I now value the simplicity of HTML forms created on the server and presented to the client. And I keep thinking how much of a shame it is that the DOM couldn't be rewritten from scratch to be easier for programs to work with and JavaScript didn't mess up the scope of variables declared in function calls. And it really bugs me that some sales person renamed LiveScript to JavaScript to be trendy, just confusing everybody.
|
|
|
|
|
Doesn't matter what you learn: the "employer" will always require at least one more obscure tech skill that you don't have.
Eventually, you will stumble into something you haven't dealt with before and that will require you to learn a completely new skill set in a week (because saying you don't know how to do something is lame).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
|
Luca...
I ran into the same issues that you experienced with ASP.NET MVC. IN 2010 I worked on one of the largest MVC projects in the United States at the time.
Though we accomplished a lot, the project was canceled due to massive management issues between the client's management and my own firm's own management.
However, the decision to use ASP.NET MVC played a major factor in this cancellation due to the fact that there was little way to accommodate large requirement changes to the interface.
As a result, after I left this assignment I gave up working with MVC and stuck with WebForms for the rest of my years in corporate positions and consulting contracts. And now that I am retired and working on my own development projects, I still won't consider relearning MVC for web development.
To begin with, there is nothing new or radical about the MVC paradigm. It was actually designed back in the 1970s.
ASP.NET already had a complete implementation for MVC with the Castle Project's, Monorail Environment. It was Open Source and completely free to implement with full documentation but it didn't seem to register with the larger technical community.
When Microsoft introduced their own version of ASP.NET MVC it was a complete mirror image of the Castle Project's implementation. I always wondered if they had made some type of deal with the people at the Castle Project.
In any event, many developers claim that ASP.NET MVC provides better performance and a superior separation of concerns among other positives. However, this is all complete nonsense since the negative aspects of MVC detract so much from its benefits as to neutralize them completely.
ASP.NET MVC is much harder to learn than WebForms and the complexities involved make it a much more difficult environment to work with, since so much is based upon JavaScript. This last makes debugging a much more difficult endeavor.
If you design a WebForms application properly and use the recommended hardware and application server recommendations that have been developed over the years, ASP.NET WebForms can be blistering fast. And in some benchmarks has equaled or exceed the capabilities of its MVC sibling. And the bigger the MVC application, the larger the routing requirements, which have always been a large bottleneck for MVC since it has historically relied on Reflection (unless that has been changed in the most recent version upgrade).
The problem with WebForms is the same with most technologies; people make a mess out of their implementations and then blame the environment for the issues. This has been particularly attribute to many developers loading up Code-Behind modules with everything but the kitchen sink when in fact this module was only supposed to act as a dispatcher for other tiers. However, what happened here was that many organizations didn't support actual tiered development and threw everything onto an IIS application server even when the assemblies were supposed to act as separate tiers.
The benefit of having multiple, physical tiers was proven in the 1990s but no one was paying any attention.
ASP.NET MVC then took off because many developers, especially the newer ones to our profession, were under the misguided perception that it would cure the WebForms bloat, much of that being the fault of the developers themselves with quite a bit of help from the hardware people who wouldn't support physical tiers.
To add injury to insult, new paradigms came to the fore (ie: DevOps), which relied on the so called faster developments of MVC under the Agile paradigm. As a result, what you have now is the equivalent of a software version of the US Air Force's F-35 fighter; a development environment that was premised on an existing concept that was never designed for large scale development. In the case of the F-35, the US Marines insisted on the basis of a flawed air-frame design that had already been proven to be unfeasible for multi-role purposes (ie: the Marines Super Harrier, which was designed for immediate ground support and light interceptor work based off of the British Harrier design. This latter design was fought to a standstill by the Argentinian Air Force during the Falklands War in the 1980s.).
This all being said, there is an indication that Microsoft may be working to return to its WebForms roots with the introduction of Blazor, which allows you to use C# on the front-end. Now the questions comes up, what do you do with all those JavaScript frameworks and components since if they are still to be used alongside C# one would then have to support three languages on such web development; HTML, C#, and JavaScript.
I suggest that Microsoft is looking for a compromise between the MVC and WebForms paradigms, considering that a whole new slew of components will have to be designed to take advantage of Blazor. And will this mean an option to return to the use of server-side controls?
Here is a link to a new essay on the same subject but in broader terms... http://tonsky.me/blog/disenchantment/
27.09.2018
And here it comes from Microsoft; a possible return to a very new WebForms...
"Microsoft is also working to implement Razor Components, or server-side Blazor, in version 3.0, which integrates Blazor into ASP.NET Core and allows it to run on the server with .NET Core. This can greatly help the compatibility of web apps, as the same code can run on many of different devices using WebAssembly, without any code changes required. .NET Core 3.0 doesn't have a set release date yet, but it will be available in public preview later this year."
Taken from the following recent article...
https://www.neowin.net/news/heres-whats-new-and-coming-to-net-core-with-versions-21-22-and-30/
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
modified 27-Sep-18 9:52am.
|
|
|
|
|
Our large bank recently changed their Android app so you can no longer paste a password. 
This is a MAJOR problem if you're using a password manager. I don't type passwords any more.
I contacted them (via their Twitter support) and explained that this is a security fallacy that pasting is dangerous.
Also, you can still paste a password when you login on their web site.
I wanted to mention that to them but was afraid they'd stop it there too.
May Only Prove That The Bank Devs/ Contractors Are Clueless
To me this only exposes the fact that the developers or security contractors or whatever actually have NO CLUE about WHAT SAFE PRACTICES are.
They could even remove copy functionality separately and I would be ok with that. But how could the paste functionality EVER be an exposure? They are just so clueless. 
EDIT 09/24/2018
Look what I found from the National Cyber Security Centre:
Let them paste passwords - NCSC Site[^]
And it provides additional links as to why pasting should be allowed.
I tweeted this to the bank site.
EDIT 2 09/24/2018
Check out this Wired article and the associated quote:
https://www.wired.com/2015/07/websites-please-stop-blocking-password-managers-2015/[^]
Wired: But accounts aren't broken into by repetitive copy and pasting. One hacker told WIRED that disabling paste on a webpage does not stop him from using automated tools to speedily gain access to users’ accounts.
modified 24-Sep-18 15:13pm.
|
|
|
|
|
A large bank will have a dedicated team of security idiots people who will listen to the latest gossip, read what is shoved under their nose and get the developers to implement the policies they think up. If there is nothing to change they will think up something to do, a team has to justify his existence.
You cannot blame the developers for such idiocy, they may even have protested the change.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: security idiots people who will listen to the latest gossip, read what is shoved under their nose and get the developers to implement the policies they think up. If there is nothing to change they will think up something to do, a team has to justify his existence.
That's a great explanation and exactly what I thought.
Mycroft Holmes wrote: You cannot blame the developers for such idiocy,
Very good point and I guess I was really thinking of the security team...not the devs.
Over all it is just craziness. Making things unusable so the security team can feel like they're doing something important.
|
|
|
|
|
As much as I denigrate them for some of their blunders I would not have their job for quids. Trying to keep in front of the bastards attempting to hack the banks must be a nightmare.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Trying to keep in front of the bastards attempting to hack the banks must be a nightmare.
Yeah, I can agree with that. But, it seems like they'd focus on creating the smallest exposed footprint and work on that instead of things like the paste feature.
I can't actually imagine the security people explaining how the paste feature could be dangerous.
Security guy: So, yes, we must remove the user's ability to paste into the pwd field because it is extremely dangerous. It's huge security hole.
Bank's IT Manager: Can you give me 2 examples of how pasting into that field would be dangerous?
Security guy: Well, they could paste special extended characters, maybe?
Bank IT Manager: Shouldn't the back-end handle that?
Security guy: well, they could paste um...errrr...well, pasting is just bad that's all. Andy why would any legitimate user want to paste? I think only crackers paste.
|
|
|
|
|
I know of a certain national bank that only allows letters and numbers. No punctuation or special characters. I swear they actually WANT their customers to have their accounts ripped off.
|
|
|
|
|
Dave Kreskowiak wrote: I swear they actually WANT their customers to have their accounts ripped off.
It really does feel that way in some of these cases, because the logic they use is so bad.
I also know that many only allow your password to be only 16 chars in length (or shorter) even though password length is the one thing that actually strengthens passwords. It's crazy.
|
|
|
|
|
I know some than only use a PIN 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: I know some than only use a PIN
And that is a perfect additional example of the contrast you find. Some sites remove functionality that is completely safe, other sites just open the door for the thieves.
|
|
|
|
|
I completely understand your frustration. I also hate websites (mostly banks) that disable pasting on their websites and just for gigs, they'll need me to type certain things like account numbers, BSB code, etc. twice.
I use Don't F*** With Paste[^] extension on Chrome and tell them straight off. I'll copy, paste, cut, do whatever the hell I want on my computer. I will treat any entity that assumes an intellectual high-ground (while knowing next to nothing about security in reality) with great disdain, and will override their "security rules" with extreme prejudice.
I'd have rambled on a bit more if this was the soapbox, but the kid sister is watching so I'll go play merry-go-round instead. 
|
|
|
|
|
Rajesh R Subramanian wrote: I will treat any entity that assumes an intellectual high-ground (while knowing next to nothing about security in reality) with great disdain, and will override their "security rules" with extreme prejudice.
I think disabling paste in password boxes are a great idea when it comes to securing customers, their data and money. Please tell me what you think of me now (give your best shot!). 
BTW, thanks for that extension.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
|
Raj is (or was?) a nice guy.
Come to think of it, with Aussies and their compulsive behaviour to shorten up words, you might as well be referred to as Raj.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
lw@zi wrote: Come to think of it, with Aussies and their compulsive behaviour to shorten up words, you might as well be referred to as Raj.
It's kind of why I said it's likely to be "another Raj". That, and the outsourcing to India.
|
|
|
|
|
Thanks! It is very refreshing to hear from others who really loathe these bad policies too.
|
|
|
|
|
Does your password manager not offer an option to simulate keystrokes to enter your password, rather than blindly relying on the clipboard?
(I have no idea - I don't use a password manager - at least nothing that'll try to type in anything for me out of "convenience")
|
|
|
|
|
dandy72 wrote: Does your password manager not offer an option to simulate keystrokes
Simulating keystrokes is more difficult in an Android app and it is the Android app that they (bank) removed the paste ability from.
|
|
|
|
|
I see.
As far as I'm concerned...considering the number of Android devices out there that have known exploits that'll never be patched, because OEMs can't be bothered...all banks should block Android altogether.
I rarely side with banks, but Android device vendors are downright irresponsible. IMNSHO.
|
|
|
|
|
Ok, I can accept that Android devices are vulnerable. That's fine.
But, then, the resolution for the bank is not to disallow pasting...it is to disallow the use of an Android device altogether. In other words, they shouldn't have ever created an Android app in the first place. I would accept that decision more readily than the blocking paste solution.
But then that would mean they needed to block the web site from Android Web browsers too. 
It would be interesting and funny if the bank just came out and said, "Sorry, you can only use our e-banking via Apple devices."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
