Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Eve

Pages: [1] 2 3 ... 540
1
General Board / Re: Can no longer post SQL Statements to this forum
« on: August 12, 2025, 02:23:30 pm »
I have never seen the configuration for Cloudflare, or the source for this forum. I don't want to do either.

If I assume this software is nearly perfect, but in some obscure function there is a single user input that isn't properly escaped. That's where a black box protection from Cloudflare is useful. It's not about anything being known to be broken it's about the problems that we don't know about.

I'm not sure if disabling this feature will really decrease the security.
You can argue that it's being excessive, I wouldn't necessarily disagree. The only way removing it wouldn't decrease security is if you are 100% sure that the forum and entire website is 100% bug free. I'm not convinced anyone can be 100% sure about anything or any software can be 100% bug free. By that measure, it is providing at least some security.

If you are not comfortable to disable this feature in Cloudfare, you should really not be comfortable to be using this forum software and update/change is ASAP.
I wouldn't be comfortable to change any setting in Cloudflare. That has nothing to do with this software.

2
There is no Table metaclass.

3
allows you to build a REST-API for EA[/li][/list]

https://sparxsystems.com/products/ea/17.1/eula.html

Quote
Server based installations that provide concurrent end users with content or functionality derived from a running remote instance of Enterprise Architect over a network is not officially supported by Sparx Systems. (This is due to technical limitations in the Enterprise Architect product, specifically its construction as a single user application interacting with the desktop UI). If you wish to deploy or use Enterprise Architect in this manner, as a minimum you MUST adhere to the requirements detailed below and further elaborated here: https://sparxsystems.com/products/ea/server-legal.html and accept the risks and responsibilities attendant on that;

  • Every end user MUST have a genuine Enterprise Architect license of the correct edition;
  • The end user must have a licence under their own name, even if that licence is obtained by that user's organization on that person's behalf;
  • Sub-licensing Enterprise Architect by 3rd Parties to end users is not permitted;
  • A Fixed license per end user is required without exception. Licenses cannot be dynamically allocated or transferred between end users;
  • Unlimited Read-Only and/or Unlimited Read/Write access to a server based instance of Enterprise Architect is expressly forbidden as unlicensed end users may be illegally authorized (with or without their knowledge) to use the Enterprise Architect instance on the server.
  • A server based instance must NOT be used to create a derivative work, adapt Enterprise Architect for another platform, virtualize separate functionality or otherwise contravene the rights and entitlements granted to Sparx Systems under copyright law and not expressly granted to the end user in the Enterprise Architect EULA.
  • You acknowledge the risks and limitations inherent in using Enterprise Architect in a manner that is not supported nor recommended and waive all rights and warranties pertinent to this use.
By my interpretation you are telling people how to violate the EULA that you have agreed to.

4
General Board / Re: Posting UML/SysML Diagrams to this Forum
« on: July 21, 2025, 09:23:03 am »
I'm taking a leap and imagining something like a super-lite version of WebEA or EALite embedded into the forum toolset.
The forum already allows exactly the same amount of diagram creation as either of those tools. ie. They don't allow you to create any diagrams, they only allow you to view them.

But ultimately, what you are asking for is: For us to create an entirely new UML design tool, even if it is a limited one.

5
General Board / Re: Can no longer post SQL Statements to this forum
« on: July 21, 2025, 09:18:57 am »
this is very specific and a very Sparxian solution was implemented.
What exactly are you saying? What is a Sparxian solution and why is Cloudflare implementing one?

The forum allows me to post the statement below
the forum allows posting some really simple SQL statements
Again, it's not the forum allowing it or not. It's Cloudflare.

6
General Board / Re: What does the Package_ID in t_object represent?
« on: July 21, 2025, 09:14:09 am »
If you have A selected (or specify its id/guid):
  • t_object.Package_ID = #Package# will give you A100 only
  • t_object.Package_ID in (#Branch#) will give you A100 and A120

Look at any package in your browser:
  • t_object.Package_ID = #Package# will give you the immediate children
  • t_object.Package_ID in (#Branch#) will give you everything you get using an expand branch (or *)

7
General Board / Re: What does the Package_ID in t_object represent?
« on: July 17, 2025, 11:42:12 am »
I guess in both cases it is the identifier of the container package.
Yes.

The reason for the question is that I am trying to understand what the #Package# and #Branch# macros pass as their parameters. The package_id from t_package, the object_id from t_object, or the package_id from t_object.
Package_ID = #Package# or Package_ID in (#Branch#)

Only #Branch# has any kind of parameter and it takes the id or guid of the root package when you want that explicitly specified instead of using the currently selected package.

Quote
There are three permutations of this macro:
    in #Branch# - gets the ID of each child Package of the parent Package selected by the user
    in #Branch=<GUID># or #Branch=<ID># - gets the ID of each child Package of the parent Package specified by the GUID or ID
    in #Branch=<ID>,<ID>,<ID># - gets the ID of each child Package under each parent Package specified by its ID

8
Just to be clear, I am not asking and will never ask for weaking security. However, Reddit and Stack Overflow support including SQL statements and do not class it as a SQL Injection, and, from a user functionality point of view, I do not see why this forum should no longer support the inclusion of SQL Statements in posts.
You are explicitly advocating to remove a security function. It may be excessive in its implementation but that doesn't change that it is still a security function.

Furthermore, the implication is that the software running the forum, which was not written by Sparx Systems, is unsafe, subject to SQL injections.
No, I'm stating that the cautious approach is to assume that unknown vulnerabilities may exist in any software.

9
General Board / Re: Can no longer post SQL Statements to this forum
« on: July 08, 2025, 08:40:25 am »
I am wondering if there is a way to require each line to have a character that would make a SQL injection impossible.
If there is I imagine it would need to be checked on Cloudflare's side.

Another possibility is giving the members (at least the ones with some history) the ability to attach files.
It's possible in the forum software and I don't know how Cloudflare would interact with it. The most difficult thing with that is that it is also a potential vulnerability for end users.

A third possibility is having a moderator OK all messages that contain SQL. I'm sure there might be some members who would volunteer for that.   
Would still require a hole in Cloudflare's protection and if it's part of the forum software that means it's going into a database.

As the saying goes, "Where there is a will, there is a way"
Which is why global protection like this is useful.

10
General Board / Re: Can no longer post SQL Statements to this forum
« on: July 07, 2025, 08:30:17 am »
Yes, someone from Sparx Systems is reading it. No-one from Cloudflare is.

The bad news that someone (me) will advocate against weakening the security. The good news is that I have no input on configuring Cloudflare (if it even is configurable).

Even if the weakening was only applied to this forum it would only be appropriate if we could say with 100% certainty that the forum code that we didn't write is 100% free from potential SQL injection. I don't think we can know that.

So, this inconvenience is a cost of security.

11
Happy to share it after Sparx Systems fixes the security issue with this forum preventing creating posts with code samples including SQL Statements.
I have nothing to do with the administration for our website, but from what I'm aware what you're describing as a security issue is that the Cloudflare SQL injection protection is stronger than you would like in this particular instance.

Yes, it's technically an issue that you are experiencing with the security for the forum. But what you seem to be asking for is removing/weakening that security.

12
As for why I'd want to do this: I, long ago along with a lot of the software world, moved away from putting the "type of the thing in the name of the thing" when it can otherwise be inferred from context - e.g. in code, I don't say
Code: [Select]
int intValue = 1;but instead
Code: [Select]
int value = 1;and it's the same here - it just feels clumsy.

I traced this back to the SysML 1.5 (and 1.7) specification but it doesn't say anything on the matter. It gives an example of applying the same stereotype to different metaclasses and applying the same properties (which is what EA does), but doesn't seem to explicitly include or exclude using the same-named stereotype on different metaclasses.
If it helps, the profile is a Namespace. Two stereotypes with the same name are not distinguishable from each other. (Look for isDistinguishableFrom in the UML specification, which is not overridden by the Stereotype class)

To compare it to your code example, if you needed an int value and a float value in the same namespace/scope you would need to rename one or both.

13
We recommend removing the relevant files from the EA installation folder, located at: C:\Program Files\Sparx Systems\EA\MDGTechnologies
That advice is so bad I'm going to track down who gave that advice and ask them to send you a retraction and apology.

As described by Geert, perspective sets are the way to do this. It allows you to limit the technologies available to all users of that model or limit specific user groups in your model.

14
I'm not sure if the developers of LemonTree are active on this forum. I'd recommend directly sending them a support request.

15
Could you tell me please why VCEs are the correct way to manage multiple copies of elements on a diagram? How tells us that only an element can be represented only once on a diagram?
Paolo's reasons are probably different from mine, but we looked at the kinds of diagrams users were saying they couldn't create because of the limitation of showing each element only once. The common story was that a complex layout meant they needed a way to show one end of a connector closer to the other end. That's what was implemented.

Issues are in fact: no possibility to resize, and not possibility to not use rectangle notation.
Neither of those are reasons why the virtual connector end is an inappropriate solution. I would describe them as a request for more options for the existing feature.

Pages: [1] 2 3 ... 540